コーディング規約

複数のプログラマーが参加しているプロジェクトには、大抵コーディング規約と呼ばれる約束事があります。 例として、以下のようなコードを書いたとします。

int cnt = 0;
int loopnum;
const int loop_max = 10;
const char *OutputFormat = "合計値は%d\n";
for (loopnum = 0; loopnum < loop_max; loopnum++) {
 cnt++;
}
printf(OutputFormat, cnt);

上記はループ回数を数えて結果を出力するコードで、期待通り動作をします。 ですが、上司、またはチームメイトからは、変数名がコーディング規約に沿っていない、と改善を指摘される事でしょう。 変数の命名はローワーキャメルケース（すべて小文字、最初以外の単語の区切りは大文字。例：loopNum）で統一する事、となっているなら、そのように改善しなければなりません。 コーディング規約は、コードの品質を保持し、メンテナンス性を向上するためなど役割は色々ありますが、プログラマーが判断に迷う色々なことを予め定めるなどして、負担を軽減してくれるものです。 変数名のつけ方などはベテランになっても毎回悩むものですから、ありがたい存在です。 そうしてコーディング規約に馴染むと同時に、他のプログラマーからコードを見られることを意識するようにもなります。 見られても問題ないプログラムを書けるようになっていくわけです。 反面、自分のやり方を押し通すことは出来ないので、ストレスを感じながらも従わなければならない場面もあります。 そのストレスの原因が、単に自分の今までのやり方とは違うからか、明らかにおかしい規則に従わなければならないからか、で対処は様々です。 自分の今までのやり方とは違う場合、まずはそれは正しいものだったかどうかの振り返りの機会となります。 例えばある言語で、今までの自分の変数はローワーキャメルケースだったが、プロジェクトではローワースネークケース（すべて小文字、単語の区切りはアンダーバー。例：loop_num）だった場合などです。 言語によっては変数に命名規則があるので、プロジェクトはそれに従っていた、と判明したら、そこは素直に自分の間違いを受け止め、成長としましょう。 明らかにおかしい規則の場合、それを進言できる機会もあるでしょうが、大抵は許容を求められます。 その場合は、変な癖として自分に定着しないように心掛けながら割り切ることになるでしょう。 しかし、変な癖と判断する基準は何でしょうか？

上記の例はすでに動いている複数人のプロジェクトですが、個人で完結する開発の場合も、命名規則を統一するなどのコーディング規約を自ら課すメリットはあります。 例のコードのように変数の命名規則がばらばらだと、それがノイズとなってコードを追う時に負担となるからです。 特に、「loopnum」のような単語の区切りがない場合は、変数の意味がぱっと分かりません。 コードを記述しているときは覚えていても、１か月後のあなたは色んなことを忘れているもはや他人ですので、やはり大変です。 命名規則一つとっても、後々の影響は大きいのです。 ですが、一度命名規則を意識し始めると、新しい言語を学ぶときに「この言語に命名規則はあるか？」とその言語を一歩深く学ぶ姿勢が身に付きます。 そうやって、コードをコーディング規約と言う別の視点から眺めることが出来た時、プログラマーとして一皮むけたと言っていいでしょう。 なぜなら、その時にはすでに、完全に動作するコードを書くのは当たり前になっていて、別の事に気を回す余裕が出来ているからです。 それは、プログラマーとして確かな芯が育った証でもあります。 そうなると、他のプログラマーのコードに触れた時に、そのプログラマーの癖に気づけます。 その癖を、良いと思い取り込むか、変だと思い参考のみにとどめるか、自分の中に判断基準が根付くのです。

今回はコーディング規約の命名規則に重きを置きましたが、他の規約も同じく気づきのきっかけとなります。 自分のコードに自信がない人はコーディング規約からそれを授かればいいと思います。 自信がある人は、それが過信にならないように戒めとしてコーディング規約を振り返るのもいいでしょう。 コーディング規約を、プログラマーを縛るものとしてではなく、成長を促すものとして見てみましょう。 いずれにしろ、人に見られた時に、芯のある説得力に満ちたコードをかけるようになりたいものです。