コーディング規約についていろいろ考えるイー・エルダーブログ【2025年1月】

更新日 2025年1月18日

コーディング規約

コーディング規約

コーディング規約が必要な理由は、既にご存知の方がほとんどだと思うが、だれもが好きなようにコーディングしてしまうと、可読性が極めて低い、読めないソースコードが出来上がってしまうからだ。

あらかじめルールを決めておくことで、可読性を担保できる。

特に、変数そのもの、変数の接頭辞は規約を作っておくことで、その変数が何を表しているか、どのプリミティブ型か、一目瞭然になる。

大昔、VBで変数に日本語（2バイト）を使ったアホがいたが、こういうアホや、for文のカウンターに、i、j、k、などはよく使用するが、i1、i2、i3・・・・のようなマジで読めないソースコードを書くアホを駆逐する為にコーディング規約は重要だ。

※個人的には、カウンターはcntI、cntJ、cntKのような接頭辞を付ける方が好きだが、これはソースが好きか醤油が好きか？という議論になると思う。

業務アプリなどでは変数そのものを規定する事も多い。「契約 contract」「検査 inspection」「予算 budget」「支払 payment」「委託事業 project」「補助事業 grant」など予め単語と変数名を決めておくことで可読性を担保できる。

「契約 keiyaku」「検査 kensa」「予算 yosan」「支払 shiharai」「委託事業 itaku」「補助事業 hojo」のようなローマ字での記述も馴染みがあるし、命名規約に定義しておけば可読性は上がるので、ローマ字記述でも良い。

※ローマ字記述がダメというプロジェクトも散見するが、意味不明な英単語を付けられるよりは、ローマ字記述の方が可読性は確実に高いので無理に英語を使用する必要はない。重要な事は可読性を第一に考える事で、英語にこだわって可読性を損ねるのは愚の骨頂だ。

プログラムは英語そのものだ。if、for、switch、do while、public、private、add、get、set、put、trim、claer、remove、などなど。

クラス、メソッド、プロパティ、変数、それぞれ正しい英語表記で命名すれば、英文としてきちんと読めるようになる。

英語圏の人（英語ができる人）にとっては単なる文章なので、普通に読めて当然だ。

問題は英語ができない日本人で、英語ができない日本人にとって、forも、ifも、switchも、すべてコマンドとして認識しており、クラス、メソッド、プロパティ、変数もそれぞれ、単なるコード（バーコードようなもの）化してしまう。

その結果、作成されたソースコードは全く読めないものが出来上がる。

UNIXのソースコードを読んだことがある人は、おおよそソースコードは読み物であると理解している。可読性は高くはないけどね。

※困るのが、英語を普通に読み書きできるが、アホで英語のできない日本人を考慮しないプログラマーだ。彼らは思いつくままソースコードを書いた結果、英語のできない日本人には読めないソースコードになる事があるので、嫌がるが規約で縛りつけるしかない。

日本語しかできないコーダーはとても多いので、コーディング規約、命名規約で縛りつけて、可読性を担保する事が重要だ。

どのようなクラス、メソッド、プロパティにもコメントは必ず書く必要がある。コメントの記述ルールもコーディング規約で細かく定義する必要がある。

「コメントの始まり、機能、引数、戻り値、コメントの終わり」など、記述方法をキッチリ決める必要がる。

特に「javadoc」や「サードパーティー」のドキュメント出力ツールを使用する場合は、100％使用するツールに沿って記述する必要があり、例外は許してはいけない。

よく使う英単語。