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

【2】どのように秩序立てればよいのか？（2/2）

● 機能別ファイルと共通部品のくくり出し

　商用開発されるようなソフトウェアは，かならず機能ブロックが分けられており，それぞれに担当が定められています．コーディング規約はここでどういう役割を果たせばよいのでしょうか．

　Dさんは機能ブロックごとにヘッダ・ファイルを分けることにしました．「この後，2次開発，3次開発を行う場合，機能ブロックごとにヘッダ・ファイルを更新してもらえば混乱しないはずだ」と考えたからです．

　では，機能ごとに共通の部品はどうするのでしょう．機能ごとに開発を進めるにしても，共通部品というものはかならず出てきます．これらをじょうずにまとめていくのがうまい設計のやりかたなのですが，これをコーディング規約に反映させない手はなさそうです．

　例えば，最初は機能ごとにルールに従ってソース・コードを作り込んでもらいます．そして，しかるべきタイミングで打ち合わせを行うなどして共通部品をくくり出し，それらを共通ヘッダに入れる，という方法で共通部分をくくりだすことができそうです．

　つまり，ヘッダ・ファイルとして次の2種類を用意することになります．

• 各機能別のヘッダ・ファイル
• 各機能共通のヘッダ・ファイル

● 構成を決めたら順番も決める

　次はdefineやtypedef，プロトタイプ宣言などを実際にヘッダ・ファイルにまとめ直す段階です．

　ヘッダ・ファイルの構成は前述したように，「記述の順番を決めて，すべての定義を一つのヘッダにまとめる」という方法が一つあります．ただし，この方法を用いると行数が多くなり過ぎたり，書き換えが頻繁に発生してしまいます．そこで，一つにまとめると混乱が生ずる場合は，defineやtypedef，プロトタイプ宣言ごとにヘッダ・ファイルを分けて，「専用のヘッダ・ファイルにそれぞれ定義する」という方法を採用します．

　後者の場合，各ソース・ファイルにインクルードするヘッダ・ファイルの順番を決めておき，その後，「各ソース・ファイルは決められた順番でヘッダをインクルードする」ようにすると，混乱は生じなくなります．この構成ならあえて多重インクルードを行う必要はありません．つまり，コーディング規約として多重インクルードを禁じてしまうことができます．

　上述のようなコーディング規約を用いていれば，Dさんのプロジェクトで起こったテーブルやdefineをめぐる大混乱は救えたことでしょう．

　複数のソース・ファイルで利用されるようなさまざまな定義は，一定の規則に従ってヘッダ・ファイルを構成してそこで集中管理すれば，開発に秩序をもたらしうる性質のものです．以上をまとめると，図8，図9のようになります．

図8　ヘッダ・ファイルによる管理の全体像
種類ごとにヘッダ・ファイルを分けた例．規模の小さい場合，すべての定義を一つのヘッダ・ファイルにまとめたほうが見やすくなるかもしれない．

図 9　共通部品化と機能分けのやりかた
図8のようなやりかたを各機能ブロックで行う場合，共通化したい部品がでることがある．それらは共通ヘッダにまとめて，各機能ブロックでインクルードできるようにする．