俺的リーダブルコードチートシート
- 他人から見て理解しやすいコードを作れ。場合によっては、簡潔/少ないコメントはマイナスに働くことに注意(条件分岐などを過度に短略化すると後で分かり辛い)
- 変数名に情報を詰め込め。例えば何か情報を取ってくるget関数なども、どこからなんの情報を取ってくるかで名付け方をgetFrom()/fetchFrom()などに変更した方が良い
- 変数名に値の単位/暗号化の有無などの情報を追記するのは◎
- ローカルな変数であればあるほど良い。また、その方が変数名の省略をしても問題が起きづらくなる
- 限界値はmin/max，以上以下はfirst/last,以上未満はbegin/end
- bool値を持つ変数は，先頭にis/should/has/canをつける&肯定系で名付けるのが吉
- 空行を使ってコードを段落分けしろ
- 重複処理はclassや関数を用いて簡潔に
- すぐに分かること/関数名や変数名の意味を補うコメントはしない
- コードの欠陥，定数やアルゴリズムの設計背景，コードの全体像はコメントすべし
- やばいと思ったこと，疑問に思ったことはガンガンコメントすべし
- 関数の入出力は実例を書くと◎
- インラインコメントで不明な引数は説明を付け加える
- コメントに代名詞は避ける
-
if 10 < widthよりもif width > 10(調査対象>比較対象) - 条件分岐では「目立つもの」「単純なもの」を先に書く。また、条件は肯定で書く
- 三項演算子は「複数の条件の中から1つを選ぶ」際に用いる
- ネストは出来るだけ浅く(失敗を先に出す等/早めにreturn/gaurd節を用いて正常系と異常系を分ける)
- 式の意味を表す説明変数/要約変数を導入する
- ド・モルガンの法則
not (a and b and c) ⇄ (not a) or (not b) or (not c)またはnot (a or b or c) ⇄ (not a) and (not b) and (not c) - 複雑な式を分割していない/理解を促進しない/中間結果に過ぎない変数は使わない
- 変数は出来るだけローカルに(1度しか宣言しないレベルで)
- 関数は出来るだけstaticに．大きなクラスは小さなクラスに
- プログラムの目的に無関係なコードは分離すべし
- 汎用コード化しよう
- プログラムで行うタスクを列挙し、1度に1つのタスクをする
- ディディベアに話しかけるようにコードのロジックの流れを説明できるようになれ
- 出来るだけライブラリに頼ってコード量を少なくするべし
- 単一責任原則:変更する理由が同じものは集める/違うものは分ける
Author And Source
この問題について(俺的リーダブルコードチートシート), 我々は、より多くの情報をここで見つけました https://qiita.com/_Masa_asaM_/items/6136f8faeba4b380dcfb著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .