新人技術者のためのロジカル・シンキング入門（5） ―― ソース・コード規約の作り方

【3】規約を考えるうえでのポイント（1/2）

　以上，コーディング規約の作成にあたっての具体例を挙げました．次に，一般的なコーディング規約を考えた場合に重要となる事柄について述べます．コーディング規約を考えるうえでは次の2点がポイントとなると考えます．

• 設計工程での検討もれは規約では救えない
• 規約は設計方針と調和させること

　順に解説していきます．

1） 設計工程での検討もれは規約では救えない

　最初に強調しておきたいのは，コーディング規約はあくまでコーディング工程の管理方針だということです（あまりにあたりまえのことのようだが...）．しかし言い換えれば，コーディングより上流工程における設計などに欠陥があって混乱が生じていた場合は，コーディング規約を定めたところで解決策にならない，ということです．

　すなわち，設計工程での検討もれは，コーディング規約では救えないのです．救えないばかりか，そもそも守れない規則ができ上がってしまい，混乱は増すかもしれません．

　そのような例としては，本連載の第2回で紹介したように外部変数が無秩序に使用されているプログラムが挙げられると思います．このようなプログラムにおいては，外部変数の管理方針を規約で定めたところでソース・コードの保守性はたいして向上しません．なぜなら，外部変数の無秩序な使用は，データ構造の再検討を抜きにしては解決のしようがないからです．

　すなわち，システムにとって必要とされるデータ構造はどのようなものかを検討し，それを設計に反映させるようにしないと保守性は改善しないということです．

　設計段階での検討がコーディング規約に先立って重要となる場合，図9で記述したような共通化と機能分けを例にとって考えてみることにします．

　この共通化と機能分けという作業は，当然のことながら設計段階で検討すべき作業です．コーディング規約は，この設計段階での検討がスムーズに実装に移せるようにするくふうにほかなりません．

　第3回で記述したように，システムの機能分けというものは設計の最初の段階で考えられる事がらです．そしてその機能分けに従って担当が割り振られ，工程表が組み立てられます．

　そのような場合，もちろん各機能で用いられる共通モジュールなどが必要となってきます．ヘッダ・ファイルの共通化と機能分けの方針は，このような設計段階からの共通部品のくくり出しと機能分けを具体化するコーディング工程における作業なのです．

　したがって，設計段階での部品共通化に問題がある場合は，後工程のコーディング規約でそれを救うことはできません．設計段階で検討すべき事がらをコーディング規約で救おうとしても救いきれないということです．

　図3で，論理値が機能ブロックごとにバラバラな例を挙げました．各機能で共通に扱うような論理値は，ほんとうはコーディング前の設計の段階であらかじめ定めておいたほうがよいでしょう．

　システムのデフォルト値はゼロが正しいか，非ゼロが正しいか，などということは絶対的な基準があるわけではありません．あるシステムではゼロをとればデフォルト値の意味になっていて，マイナス値はなんらかの異常を表すかもしれません．またあるシステムでは，'1'がデフォルト値であって，'2'，'3'という値はなんらかの特別な場合を表すのかもしれません．