7-1. コーディング規約の決め方・守らせ方
コーディング規約の重要性
プログラムを書く側にとっては煩わしいものかもしれません。
しかし、システムの品質を考える上で、コーディング規約が守られていることは非常に重要なポイントです。
保守・運用を行っていく上で、統一感のあるソースコードは、障害のリスク・システムの維持コストに影響してきます。
仕様の調査、改修作業、テストといったシステム稼働後に発生するソースコードを読む様々な作業において、「読みやすいコードが書かれているか」というのは非常に重要なことです。
ここでは、コーディング規約の内容そのものについては記述しません。
本来、Oracle社がはっきりと提示してくれれば良いのでしょうが、特にそのようなスタンスではないようです。
というか、Oracle社内でも統一されていないようで（既にコントロールできるものでもないのでしょう）、開発ツールのSQL*Developerでは予約語は小文字、ERPパッケージであるE-Busuiness Suiteの開発ガイドでは予約語を大文字で記述するようになっていたりします。
「Oracle E-Business Suite開発者ガイド」（https://docs.oracle.com/cd/E21372_01/docset_files/trans/E53035-01/html/T302934T307517.htm）
「大文字と小文字を使用して、コードの読みやすさを向上させます(PL/SQLは大文字小文字を区別しません)。ガイドラインとしては、予約語には大文字を使用し、その他すべてに小文字を使用することをお薦めします。」
標準化というのは決め事です。
十分な情報が行き渡るようになった今や、どちらの方法がメリットが大きいか、デメリットが小さいかの損得で決まることは、だいぶ少なくなりました。
大文字か小文字か、インデントを2バイトスペースにするか4タブにするかといった点は些細なポイントです。
最近では整形ツールも充実してきていますので、後から修正することも不可能ではありません（リスクはありますが）。
責任のある者が決める。それが最も重要なポイントです。
如何にしてコーディング規約を守らせるか
規約が細かく、量が多ければ多いほど、コーディングを行う側にとって、規約通りにコーディングを行うのは煩わしいものです。
また、悪気がなくても、規約の文書量が増えれば増えるほど、読み落としや解釈の誤りなどで、規約違反となるソースコードは必ず発生します。
規約を守ってもらいたければ、規約は極力シンプルであることが望ましいのは言うまでもありません。
作業効率の問題もありますので、コーディング規約はシンプルであればあるほど守りやすくなります。
プログラマに慣れ親しんだものである、というのも重要な要素です。
前述のように、プログラマがコーディング規約の全文を一言一句違わずに記憶し、１００％コーディングに反映するのは非常に困難です。
新たに覚える分量を減らすため、同じような経歴を辿ったプログラマを集め、暗黙知として身についている規約に近いものを提供することで、容易に規約通りのコードを記述することができるでしょう。
しかし、これはその時の状況次第です。
経歴もバラバラなメンバーが集まった場合にはどうしようもありません。
それでは、そのような問題を解決するにはどうしたら良いでしょうか。
解決するための方法は、以下の3点です。
レビューの徹底とツールの活用
まずは基本的な、コードレビューとツールの活用です。
レビューについては改めて言うまでも無いでしょう。
ただ、全ソースコードに対してレビューをするのでは、レビューイ、レビュワーとも非常に負担がが大きくなります。
システムの規模にもよりますが、全量のソースコードレビューが現実的ではないケースもあるでしょう。
とはいえ、プログラマ毎に最初の一本は最低限レビューすべきです。
できればそれに加え、システム中の重要なプログラムをピックアップしてレビューするのが望ましいです。
また、ツールの活用も検討すべきでしょう。
特に、ソースコードの整形ツールは、徐々に進化ており、最近ではSQL*DeveloperでもPL/SQLの整形ができるようになってきています。
これで必要最低限のフォーマットチェックは行えると思います。
共通関数の使用
標準化を進めていくと、全プログラムで同じようなコードを記述する場面が増えてきます。
第４章「共通化」でも記載したように、「ファイル入出力」「ログ出力」「バッチ処理起動」は、その最たる例です。
これらの仕組みを共通化することで、これらの処理は同一の記述となります。
各々のプログラマがロジックを記述するよりも、確実に統一を計ることができます。
注意しなければいけないのは、早期にユーザーと共通仕様の認識を合わせておくことです。
機能により担当者が異なるような場合、担当者毎の要望を個別に受け入れていたのでは、共通機能の開発ボリュームの変動が発生してしまいますし、開発が始まってから変更が入ったのでは大幅な手戻りが発生します。
「バッチ処理をどのように起動するか」「ログは、どこに、どのようなフォーマットで、最低限どのような情報を出力するのか」そういった共通仕様を早期に固めておく必要があります。
開発者側の都合で、ログの出力パターンを1種類に決めても、後になってユーザーから要望が出てきて、それを受け入れざるを得ない状況になってしまっては共通化のメリットが出せません。
こういった共通仕様を早期に取り纏め、開発者に提示することで、ソースコードの品質を向上させることができます。
サンプルコードを提供する
そして最後に重要なのが、前述のレビューや共通関数を組み込んだ状態のサンプルコードを開発者に提供することです。
１つのシステムにおけるプログラム（特にバッチ処理）のバリエーションはそれほど多くありません。
- パラメータを受取り
- パラメータ値の妥当性チェック
- 処理対象データの抽出
- データの加工（抽出時に併せて実施しておくのが望ましい）
- データの出力
- 処理結果情報のログ出力
といった流れになるのが一般的です。
もちろん業務ロジックが複雑になればソースコードのボリュームも増大しますが、それは３や４に関するデータ操作のバリエーションが増えるだけで、それは大抵標準化の必要の無い箇所です。
入力元、出力先は、そのバリエーションによりサンプルコードを提供した方が良いでしょう。
上記の内容を実現するプログラムを開発が始まる前に作ってしまい、それを開発者にサンプルコードとして提供するのです。
既に正しく記述されているコードはあれば、開発者はむやみにその内容を変えることはありません。
そのサンプルコードの必要な箇所にのみ手を入れる形で開発を始めることで、規約の遵守率は大幅に上げることができるでしょう。
