コーディング規約と生産性
適切な規約を選択し、チーム内で順守することで、コードが読みやすくなり、アンチパターンを回避できたり、不要な議論をなくすことができる。
私自身は、コードを引き継く機会もそこそこある。そういった場合には、既存のコーディングパターンに従う必要がある。
コードを編集しているとき、元のコードが、本ガイドのルールではなく、別のルールに従っていると気づくことがあるかもしれません。そのような場合には、そのコードの規約との一貫性を保つために、本ガイドのルールからは外れなくてはならないでしょう。
> https://ttsuki.github.io/styleguide/cppguide.ja.html#Existing_Non-conformant_Code
ここまでは教科書的な内容。
話が変わるが、読み手至上に過ぎる決まりは、書き手の手間を増やし過ぎるのではないかと思っていた。例えば、「末尾コメントが続く場合はスタート位置をそろえるべき」など（この状況は、デバイスドライバの定数定義のマクロとかで発生する）。
などと思っていたが、GoogleのC++の規約に以下のように言及があった。
コードの(書き手ではなく)読み手に優しいこと
我々のコードベース(と、ほとんどの個々のコンポーネント)は、今後長い長い時を経ていくことが予想されます。 結果的に、そのコードを書くのに費やした時間に比べて、はるかに多くの時間がコードを読むために割かれることでしょう。 私たちは、私たちの平均的なエンジニアが「簡単にコードが書けること」よりも、「コードを読み、メンテし、デバッグがやりやすいこと」に最適化することを明示的に選択します。
自分のケースにはめると、書いた後にメンテし続けるものはすくないので、「簡単に書けること」を明示的に選択する選択肢もあり得ると思う。
先のC++の規約では、行末の複数行コメントのインデントはそろえることを推奨している。
後続の行にも続けてコメントを書くときは、それらを揃えたほうが読みやすいです。
ちなみに、pythonのデファクトの規約であるpep8には（覚えている限り）それへの言及はないが、イコールの位置を揃えるためにスペースを入れるべきではない、とは書かれている。
次の場合に、余計な空白文字を使うのはやめましょう:
(略)
