はじめに
先日、コードレビューをするときの心構えについてなんてエラそうなタイトルの記事を書きましたが、その派生です。コードの見た目について思うことを書いています。結論的には、既存のコードと合わせることが一番で、チームの規則が二番、迷ったらGoogle C++ Style Guideに合わせるで良いかと思います。
変数名
-
英単語で書く
-
あいまいな意味の単語は使わない
-
真偽値は
isやhasで真偽値であることを示す -
スコープを示す記号はあったほうが良い
メンバー変数ならxxx_と語尾にアンダーバー、グローバル変数がもしあるならg_xxxなど。IDEは進化していますが、GitHubでレビューする場合など、変数宣言箇所が遠い場合、レビュワーの負担が増加します。 -
ハンガリアン記法は論争になるので避ける
型が変数名からわかることがメリットですが、IDEが進化しているので不要vs可読性の低下には違いない、型が変わった場合のリファクタ対象が増えるvs型が変わる設計自体がおかしい、など論争のもとになるので避けておいたほうがベターかと思います。
英単語の省略
-
よほど既知のものでない限り長くても省略しない
読み手に迷わせる可能性のあるものは可読性が低下すると考えておくとよいかと。最近は4Kディスプレイなどもありテキスト幅もそう気にしなくても良くなってきていますし。あなたの常識は一歩外に出ると常識じゃないことも考えるとなるべく省略しないほうがいいと思います。64文字なる変数を見たことがありますが、これは別の問題と思っていて、そもそも変数で何をしたいかがわかっていなかったように思います。 -
スコープが小さいほどスコープでだけ通じるよう短くする
ループ変数iは最たるものかと思いますが、検索性が落ちるのでxxx_indexなどつけたほうがいいようには思います。また、iとjとkのループ順が変わったときバグる未来しか見えないですし。メンバー変数などスコープの大きいものは、プライベート変数とまず被らないようにすると安全になります。グローバル変数
文字区切り
読みにくいなど、宗教戦争が起きやすい規則です。これも既存と合わせることが重要と思います。代表的な文字区切りを表にしてみましたが、特定の区切りを使っているものは「関数」である、「変数」であるなど、直感的に理解できることが読み手の読解力を向上させるものと思います。
| 文字区切り | 所感 |
|---|---|
| snake_case | 変数名に多い |
| camelCase | 関数名に多い |
| PascalCase | クラス名に多い |
おわりに
新規開発ならlintで命名規則を予め縛っておく、既存開発ならlintを追加導入して問題箇所をリファクタする期間を設けるなどしておくと良いように思います。可読性の低いコードは、後にじわじわと虫歯のように痛みだし、最後には悲鳴が上がることになるかと思います。現場で。