リーダブルコード 5-6章 コメントについて · GitHub
readable-code-chap5-6.md 5章 コメントすべきことを知る コメントの目的は書き手の意図を読み手に知らせることである コメントすべきでないことを知る コードを書いているときの自分の考えを記録する 読み手の立場になって何が必要かを考える コメントすべきではないこと パっとみて当たり前にわかることをコメントに書かない // 休日を計算する function caliculateHoliday() { ... } // 関数実行時の年の1/1から12/31まで、祝日を除く休日を計算する function caliculateHoliday() {....} コメントにパッと見でわからないことを書くようにしよう 関数名がひどい場合はコメントではなく関数名を書く // Kintoneのカスタマイズでコメントを128kbに制限する // コメントにはコメント内容、コメント時刻、コ
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
