Zenn
Closed27

記事にできそうなネタ帳

Zenn
𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖

JavaScript コメント使い分け

  • // 直下の処理を説明する
  • /** */ 宣言された変数や関数を説明したいとき、JSDocで書きたいときに使う
  • /* */ コメントを複数行に跨がせたいときに使う
𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖

英語できないマンが翻訳なしで情報を探す技

  • 英文の中のコードに注目する
  • 英文の中のリンクに注目する
  • GitHub Issue の場合、 fixed, solved みたいなコメントの直前のコメントを見てみる
  • etc.
𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖

タイムゾーンとSSR

𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖
  • SSR中に日付をフォーマットするとクライアントとは違うタイムゾーン（だいたいはUTC）が表示されることがある
  • これはサーバーが動いているマシンのタイムゾーンがクライアントと同一ではないから起こるので気をつけないと普通に発生する
  • サービス間での表現や処理の違いを見比べる
𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖

コードレビューのときに気をつけていること

𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖
  • 相手が否定しやすい文体でコメントする（〜と思います、〜な気がします）
  • ただし、可読性・保守性を低める書き方は明確に指摘する
  • 省略可能な記述は省略させる
    • 記述が減ることはコードリーディングを簡単にして保守性を上げること
  • 不要な型指定を減らす
    • 推論があるので不要な型指定を減らせば修正箇所を減らせる
    • 推論可能な書き方は読みやすいコードになっていることが多い気がする
𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖

コードを書くときに気をつけていること

𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖𝕤𝕚𝕞𝕠𝕔𝕙𝕖𝕖
  • 配列操作にはビルトインメソッドを適切に使う
    • 配列の個数が変わるか、インターフェースが変わるかが書き出しでわかって脳の負荷が減る
  • 型は可能な限り指定する
    • ただし、推論される箇所には指定しない
  • ライブラリ・フレームワークはスタンダードな使い方を目指す
    • 独自性を出さない
  • 自作ライブラリを減らす
    • 調査不足な状態でライブラリを作る判断をしない
  • 自分のエゴをコード・設計に出さない
    • 自分はこう書いたほうが読みやすい、この書き方で実装したほうが作りやすいみたいなのはなるべく排除して、一般的な書き方を目指す
  • コメントを書く・書かない
    • Whyについてをコメントに残すことを意識する
    • コメントを書きたくなったら一旦実装を見直してみる
  • プロパティ名をなるべく変えない
    • そのために分割代入を多用していることろある
Hidden comment
このスクラップは5ヶ月前にクローズされました