ベストなコーディング規約の作り方

投稿日 2014/12/31 更新 2015/02/23

 [Home]

このサイトは Amazon Web Service (クラウド) で構築しています。AWS に関する記事

 

コーディング規約とは

「コーディング規約」は多数のプログラマが参加するプロジェクトにおいて、プログラミング品質を均等にするために定める文書です。

内容は変数などの命名規則、禁止事項 (例えば goto 文はダメとか)、コメントの付け方とか、いろいろプロジェクトの特性やその会社の文化などで変わります。

 

コーディング規約のメリット・デメリット

コーディング規約のメリットはプログラマの個性を殺して均質なプログラムを作ること、過去の知識や経験から得られたバグの発生源となりやすいコーディングの防止、インデントやコメントの基準を決めて見やすさ保守性の高さを求める・・・等々です。

一方、デメリットですが、使える文法を制限してスキルの高いプログラマの生産性を殺したり、過去のプログラムとの互換性を追求するあまり新しい機能の使用を制限したり・・・等々があります。

一般に、大きなプロジェクトほどコーディング規約の内容は強制的、制限的です。これは、大きなプロジェクトだと、スキルの低い人もメンバーに入っていることが多く、コーディングを自由にやらせると、品質が落ちたり、プログラムが見づらく保守性が悪くなるったりするためです。

 

コーディング規約の内容

コーディング規約の内容は、プロジェクトの規模や特性、参加メンバーのスキル、使用言語などにより変更すべきですが、たいていこんな内容が書かれています。

  1. 目的
  2. プロジェクトの構成
  3. 命名規則
  4. コーディングスタイル
  5. 禁止事項
  6. 制限事項
  7. 推奨事項

目的

そのコーディング規約の適用範囲、なぜ必要なのか、それを守ることによりどんなメリットがあるかを書く。


プロジェクトの構成

コーディングにはあまり関係なさそうな内容ですが、ソースプログラムの先頭にコメントを入れたりするのに使います。プロジェクトの名称などはあらかじめ決まっていることが多いので、もし、そうなら一覧表を付けます。メタ情報の指定方法、フォルダの構成方法なども決めておきます。

命名規則

変数、定数、メソッド(関数)、クラスなどの名前の付け方の基準を決める。変数名の先頭は小文字だとか、クラス名の先頭は大文字だとかがよく使われます。


コーディングスタイル

コーディングスタイルはインデントの仕方とか、中かっこの位置とか、コメントの位置や内容とかを決めておきます。


リソース

エラーメッセージなどはハードコーディングしないで、よくリソースファイルのインデックスを指定したりします。もし使うなら、リソースの使用についての説明、制限なども書いておきましょう。(あまり大きいリソースの管理はたいへんなのでバランスを考えたほうがいいです。特に IDE を使う場合。)


禁止事項

使ってはいけない文法や今はほとんど使われない保守用になっているものとかを揚げておきます。一律に禁止でなく、場合によっては例外も設けておきます。(なぜ禁止なのか、その理由も必ず書きます)


制限事項

あまり推奨されない機能、コーディング方法、クラスなどを揚げておきます。また、その条件を明示します。


推奨事項

好ましいコーディング方法や複数の似たようなクラスや関数などがある場合、どちらが推奨されるかを書いておきます。


コーディング規約を作るときの注意

短く見やすく

コーディング規約は、できるだけ短いほうがよいのであまり盛りだくさんにしないようにします。メンバーのスキルが高い場合は、最低限の内容にした方が生産性が上がります。内容が全員によく伝わるようにサンプルを付けましょう。また、禁止事項、制限事項など、なぜそうなのかの理由も必ず書いておきましょう。


プロジェクトに合わせて作る

コーディング規約は、どこかの管理部門みたいなところが作ったのをそのまま使うのはよくありません。なぜなら、技術的に古くなっていたり、そのプロジェクトに最適になっていないためです。

例えば、メンバーのスキルが高い場合は、コーディング規約はできるだけ薄いほうがいいです。高スキル者にいろいろ規約を守らせようとすると、生産性が大幅に落ちてしまいせっかく高スキル者を集めた意味がありません。

逆に、低スキル者中心のプロジェクトならたとえ量が多くなっても、詳しく書いたほうがいいですね。もう、そうなるとコーディング規約と言うより、「コーディング指南書」みたいな性格にします。この場合は、高品質なサンプルをたくさん付けましょう。

高スキル者、低スキル者が入り混じった大きなプロジェクトでは、例外を多く認めて高スキル者の生産性を奪わないようにしましょう。


テストに対する考慮

最後に忘れてはならないのが、テストに対する考慮です。テストはプロジェクトで大きな時間を占めます。この時間を以下に減らせるかが、プロジェクトの明暗を決めます。テストのしやすさ、バグの検出のしやすさなどを考慮しましょう。


作る人

コーディング規約を作る人は相当なスキルが求められます。プロジェクトで使用する言語や環境などに対して精通している必要があります。そうでないと、「ぬけ」があったり(セキュリティに関する抜けは致命的)、禁止事項などが多すぎて開発の効率が落ちたりしてしまいます。

 

 

 


 Prev:  Next:

 開設 2014年12月   著作権 2014-2015 bonk.red  連絡先: こちらからメッセージを送ってください。(お仕事も大募集)