コーディング規約

コーディング規約（coding conventions）

コーディング規約とは、プログラムの作成における字下げや変数命名などに関する規約のことです。

コーディングはコンピュータへの処理命令作成であるとともに、他人に「何をどう処理するのか」を示す文書作成であることを認識することが必要です。
　現在のプログラミング言語文法は柔軟性に優れています。反面、人により異なる習慣や考え方により、多様な表現をすることができます。そのため、自分の流儀と異なる他人のプログラムは、違和感があり読みにくいことがあります。

プログラムは、完成するまでに多様なチェックが行われます、また、システムを取り巻く環境変化は激しく、それに対処するためにプログラムの改訂機会は増大しています。
　このように、プログラムには、作成者だけでなく、チェックをする人、機能追加や変更をする人など多くの人が関係しています。それらの関係者が誤解なくプログラムを理解する必要があります。

それには、標準的なプログラムの書き方のルール、すなわち、コーディング規約を策定することが望まれます。

代表的なコーディング規約

字下げ（Indentation）

プログラムの文の書き出し位置を、何文字分か右の方へ下げることです。
　データ構造や制御構造のネスト（入れ子）を半角２文字あるいは４文字字下げします。
　左のコードより、右のコードのほうが、何をしているかがわかりやすいでしょう。

　字下げしない　　　　　　　　　　　　字下げする
　　var x = 0;　　　　　　　　　　　　　var x = 0;
　　var y = 0;　　　　　　　　　　　　　var y = 0;
　　for (var i=0; i<=10, i++) {　　　　 for (var i=0; i<=10, i++) {
　　if (i <= 5) {　　　　　　　　　　　　　 if (i <= 5) {
　　x = x + 1;　　　　　　　　　　　　　　　　　x = x + 1;
　　y = y - 1:　　　　　　　　　　　　　　　　　y = y - 1:
　　}　　　　　　　　　　　　　　　　　　　 }
    else {　　　　　　　　　　　　　　　    else {
　　x = x - 2;　　　　　　　　　　　　　　　　　x = x - 2;
　　y = y + 2;　　　　　　　　　　　　　　　　　y = y + 2;
　　}　　　　　　　　　　　　　　　　　　　 }
　　}　　　　　　　　　　　　　　　　　 }
　　var z = x + y;　　　　　　　　　　　var z = x + y;

ネストを { } ではなく 字下げで示す言語もあります。Python や YAML など。

ネストの深さ制限

ネストを字下げすると読みやすくなりますが、ネストが何重にも深くなると理解しにくくなります。
それで、深いネストの部分を関数などにして回避するのが適切です。

       
　深いネスト　　　　　　　　　　　　　　　ネストの回避
　　if (a < 10) {　　　　　　　　if (a < 10) {　　　　function func(x,c,d) {
　　　x = x + 1;　　　　　　　　　　x = x + 1;          if (c < 10) {
　　　if (b < 10) {　　　　　　　　 if (b < 10) {　　　　　x = x + 3;
　　　　x = x + 2;　　　　　　　　　　x = x +2;　　　　　　if (d < 10) {
　　　　if (c < 10) {　　　　　　　　 func (x, c, d);　　　　x = x + 4;
　　　　　x = x + 3;　　　　　　　　}　　　　　　　　　　　}
　　　　  if (d < 10) {　　　　　 }　　　　　　　　　　　}
　　　　　　x = x + 4;}　　　　　　　　　　　　　　　　}
　　　　　}
　　　　}　　　　　　　　　　　
　　　}
　　}

命名規則

プログラマにより「得意先」、日本語を避けて「customer」、文字数を減らして「c」などと勝手に変数名を付けたプログラムは、他の人が読むには該当プログラム専用辞書が必要になります。変数名の統一は、理解しやすいコーディングのための最大要件です。

• 業務用語の統一
  「得意先」や「出荷」など業務で用いられる用語を統一し明確な定義をすることは、担当者間、部門間の誤解をなくすのに不可欠であり、情報システム以前にビジネスの円滑化のレベルで重要になる事柄です。
  システム開発の段階では、例えば「得意先名」や「得意先コード」など派生した用語が必要になりますし、プログラム作成には、それらの用語をコーディングでの変数名として統一することが必要です。
  参照：業務用語定義の重要性
• 対象分野での慣用変数名
  科学技術分野では、半径は r, 時間は t、共分散は cov というように、慣用的に用いられている変数名があります。それらの変数名を用いることは、自分がコーディングする際に文献で式を確認してコーディングする際に誤りを防ぐことになりますし、読む人も変数の意味がわかるので誤解が少なくなります。
• コーディングでの慣用変数名
  配列の添え字には、i, j を用いること、２次元配列では行番号を i、列番号を j とすることなどです。
  言語系での配慮も必要です。customer-id のように - を使うと減算になる危険性がある場合は、customerId のような記法を標準にするべきです。
• 使用禁止命令
  プログラムの前後にジャンプする goto命令 を持つ言語もありますが、これは解読性を失う大きな原因になります。それを禁止して構造化プログラムにするべきです。近年は、この命令を持たない言語が多くなりました。
  このように、一般的に非推奨とされている命令は、将来的にはサポートされないリスクがあるので、積極的に禁止すつことが考えられます。
  コーディングはプログラムテクニックの顕示の場ではありません。特殊な命令や裏技を駆使してステップ数を少なくしたり計算時間や容量を少なくしても、大多数の通常の知識しか持たない人には理解できないのでは、効果より損失のほうが大きくなります。

規格設定の留意点

規格は関係者全員が守らなければ効果はありません。そのため、次のような事項に留意する必要があります。

• 規格の管理環境を検討すること
  規格の策定、普及、維持、改訂を担当する部門と権限を検討する
  　　→弱小ならば、業務用語の統一など、広範囲にわたる規格化は困難
  　　→強力組織にするだけの価値があるかのコンセンサス
• 規格の準拠範囲を示すこと
  全社規格で全員が準拠すべき規格なのか、プロジェクト内部だけで準拠すればよい規格なのか
  　　→個々の条文で切り分けるか、体系的な規格を設けるか
  規格策定のメンバ構成に大きく影響（特に業務用語の統一）
• 規格対象の特性を認識すること
  関係者が日本人だけなのか、外国人が多いのか
  　　→変数名が日本語やローマ字でよいか、英語にするか
  プログラムは内製か、請負外注か。発注先は１社か、複数か
  　　→自社規約と発注先規約の整合性をどうするか
  このシステムは他システムと連動するか
  　　→規格の準拠範囲に影響
  使用言語を固定するか、移植性を重視するか
  　　→個々の言語の持つ特性を規格に反映させるか
• 理由がわかる規格にすること
  個々の条文は、どのような効果を目的とするのか納得できるものにすること。自明でないものには理由を示すこと
• 条文は明確にすること
  プログラマにより解釈が異なるのでは規格として不適切
  明確な規格にできない事項は、推奨事項とする。
• プログラマに受け入れやすいこと
  一般のプログラマが、それまでに受けてきた教育や経験と大きく異なる規格は、受け入れられない。
  プログラマが効果を感じない、あまりにも些細なことまで規格化すると、プログラマは負担やストレスを感じる。
  通常の能力を持つプログラマに、あまりにも高度な要求をしても、対処できない。

支援ツール

コーディング支援ツール

• コードエディタ
  通常の文書作成でのＷｏｒｄのように、コーディングにおいて、入力文字数を減らす、文法エラーをチェックする、コーディング規約にかなった記法にできるといった機能を支援するエディタの総称です。
• コード補完
  予約語の一部を入力すると、候補となる予約語リストが表示されます。
  ( や [ を入力すると ) や ] も表示されます。
• シンタックスハイライト
  可読性を上げるために、テキスト中の特定の記号やキーワードなどを他とは異なる色やフォントで表示する機能です。

静的解析ツール

• デバッガ
  プログラム中の文法上のエラー（バグ）個所を色を変えて表示。エラーの理由を示すものもあります。
• 構文チェッカ
  プログラムが、言語で定めれらた構文に従って記述されているかをチェックします。
• コードオーディタ
  プログラムのソースコードが、独自に定めたコーディング規約にのっとっているかどうかをチェックするツールです。
• モジュールインタフェースチェックツール
  モジュール間のインタフェース（例：実引数と仮引数の個数）の不一致などを検出します。
• メトリクス計測
  ソースコードの保守性や可読性を定量的に評価するツールです。
  ソースコードの規模や複雑さ、モジュール間の強度・結合度、モジュールの深さなどを、数値として計測する手法で、可読性・保守性の悪いソースコード、バグが潜在しやすいソースコードを発見することができます。
• メモリダンプ（静的ダンプ）
  プログラムの異常終了時にメモリやレジスタの内容を出力します。

動的解析ツール

• トレーサ
  エラー箇所が特定できないときに、指定範囲内の命令を１ステップずつ実行し、その実行結果や変数の値などを追跡表示します。
• インスペクタ
  構造体のようなデータ構造の内容を容易に確認できるように、見やすい形で表示します。プログラムの実行を途中で中断し、データ構造を見やすくしたり変数の値を設定したりできます。
• スナップショット（動的ダンプ）
  プログラムの特定の命令文が実行されるごとに、指定されたメモリやレジスタの内容を出力します。
• アサーションチェッカ
  プログラムの正当性を検査するために、変数の間で論理的に成立すべき条件をプログラムの適切な箇所に挿入し，実行時にその条件を満たしていることを検査する支援ツールです。

関連事項

サブルーチンや標準パターンを利用することは、プログラムの部品化と再利用の考えかたです。この考え方により、品質の良いプログラムを少ないステップ数で記述することができます。

サブルーチンや標準パターンは、言語ライブラリとして提供されるもの、市販しているものもありますが、自作することもできます。
　広範囲に利用でき、利用勝手のよいサブルーチンにするための指導原理として、モジュール分割があります。
　標準パターンを作るには、対象業務で行う処理を体系化する必要があり、その指導原理に構造化設計があります。

コーディング規約を拡大して、オーソライズしたサブルーチンや標準パターンの利用を規約として組み込むこともあります。