新人技術者のためのロジカル・シンキング入門（5） ―― ソース・コード規約の作り方
【3】規約を考えるうえでのポイント（2/2）
このようなことは，システム全体の要請を考慮しながら決定すべき事がらです．個人の好みはあっても，絶対的な正解というものはかならずしも存在しません．ただし，全体の方針で調和がとれていなかったら，確実に混乱のもとになります．図9では，共通ヘッダと機能別ヘッダを分ける方法の一例を紹介しています．このコーディング規約も，設計段階（コーディングの一歩手前の内部設計も含む）で検討した事がらを反映するようにしないと，プログラムの保守性は期待したほどは向上してくれません．
図 9 共通部品化と機能分けのやりかた
図8のようなやりかたを各機能ブロックで行う場合，共通化したい部品がでることがある．それらは共通ヘッダにまとめて，各機能ブロックでインクルードできるようにする．
2） 規約は設計方針と調和させること
コーディング規約は，設計という上流工程で定められた方針と調和したものでなければなりません（図10）．
図10 各工程の方針は互いに調和させること
開発言語の設計思想が前工程の設計作業そのものに影響を与えるというのは，教科書的な知識からは本末転倒のように聞こえるが，実際の開発では見落とせないファクタとなっている．
例えば，Javaなどのオブジェクト指向言語でよく採用されるような，クラスごとにソース・ファイルを分けてソース・ファイルと同名のヘッダ・ファイルにクラスや構造体の定義を集めて構成していくという方針をとっている場合などは，本稿で述べたような管理方針をそのまま採用できません．そのような構成の場合，プロトタイプ宣言や構造体をクラスごとに別々のヘッダ・ファイルに入れないで共通化してしまうと，ソース・コードが書けないからです．オブジェクト指向を設計方針として採用し，そのためにオブジェクト指向言語を実装に用いると，結果としてコーディング規約にも影響を及ぼすということです．
● 規則は趣旨を考えて運用する
なんらかの規則を定めた場合，それを適切に運用するには趣旨を考えることがとてもたいせつです．図4に示したようなソース・コードの管理方針の趣旨は，要するに「集中管理によって混乱を防ぐ」というものです．だとすれば，機能ごとにクラスを分けるコーディングを採用する場合も，同じ考えが応用できるはずです．すなわち，defineやテーブルに関しては，集中管理する方針が採用できるということです．
そうではなく，「ヘッダ・ファイルは，構造体やdefine，プロトタイプ宣言，テーブルに分け，各関数共通で用いるものだ」と結論だけ覚えこんでいた人がいたとしたら，やっかいです．そのような人は，ここで解説したようなヘッダ・ファイルの管理方法を身につけたとしても，慣れないプログラム言語に初めて接した場合にはなかなか対応できないことになります．
逆に，設計とコーディング規約が合致する例を挙げてみましょう．データ構造は設計段階で検討すべき事がらですが，この方針が定まったうえで，それと調和のとれたコーディング規約を採用すると，コーディングの工程における実装がスムーズに進められます．
連載第2回では，データ構造を検討したうえで，スタティック・データ，ダイナミック・データ，テーブル，ローカル変数の4種類のデータがありうることを解説しました．これらを本稿で紹介したコーディング規約にあてはめればうまくいくはずです．
第2回では，スタティック・データとダイナミック・データについては，構造体にそれぞれまとめこんでしまう構成をとるようにしていました．つまり，上述のような規約を採用する場合は，構造体用ヘッダ・ファイルにまとめて定義すればよいことになります．
テーブルについても，今回のコーディング規約で管理方針が定められています．すなわち，Cソース・ファイルに実体を定義し，ヘッダ・ファイルにextern宣言をまとめればよいでしょう．
ローカル変数は領域の小さな変数に限定して関数ごとに定義されて用いられるもの，というのが第2回における方針でした．したがって，ヘッダ・ファイルで共通管理を行う必要はとくにありません．まとめると表1のようになります．
| データ構造（第2回参照） | コーディング規約 |
| スタティック・データ | 構造体ヘッダに定義 |
| ダイナミック・データ | |
| テーブル | テーブル用ヘッダに定義 |
| ローカル変数 | ヘッダでの分類はなし |
| ― | define |
| プロトタイプ宣言 |
設計工程で検討した事がらがスムーズに実装されるようにくふうするのがコーディング規約の趣旨．したがって，設計者が開発言語に不慣れであってはならない．
