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

【1】宣言や論理値の統一に問題あり

　Dさんが平身低頭して直ちにリリースをやり直したのはいうまでもありません．

　うなだれて帰ってきたDさんは翌日，プロジェクトのメンバを集めてソース・コード・レビューを行うことにしました．そこで判明したのは，リリースしたライブラリのソース・コードはテーブルの実体宣言が機能ブロックごとにいろいろなファイルにまたがっていて，あるテーブルの実体がどこにあるかはコードを書いた者にしかわからないという事実でした（図2）．さらに問題だったのは，散らばったテーブルのうち，いくつかは機能ブロック間で共通に使われているということでした．

図2　バラバラで存在するテーブルは保守性が悪い
なぜなら，テーブルは外部参照していろいろなファイルで使うものであるため．どこになにがあるかわからないと，極めて保守性の悪いソース・コードになってしまう．

　ソース・コードをさらに細かく読み進めてみると，define文やプロトタイプ宣言のたぐいもあちこちにバラバラに存在していました．中にはプロトタイプ宣言なしで使われている関数もあるようでした．加えて問題だったのは，ある一つのdefine文は機能ブロックによって論理値が逆となっていたことです（図3）．

図3　論理値が機能ブロックによって逆という例
方針をまったく決めずに複数の人がコーディングしてしまうと，こういうことが起こりうる．防止するためには，ソース・コードの書きかたの規則に加え，必要な論理値は正負をあらかじめ決めておくというような対策が必要．

　外部変数も実体があちこちにありました．外部変数を使用することは設計段階で必要と判断したものですが，その管理に問題があることは否めないようです．構造体や変数型のtypedefも散在していることがわかりました．

● 「おまじない」にならないためのコーディング規約作り

　Dさんのような事態に陥った場合，読者のみなさんは，どういった解決策を考えるでしょうか．「そこまで自分はまぬけではない」と思う方もいるかもしれません．そういう方は，管理がボロボロのままライブラリを提供してしまう開発チームを運悪く引き当ててしまった顧客のQさんになったつもりで考えてみてください．

　まずだれでも考えるであろうことは，「再発防止のためには，ソース・コードになんらかの規約が必要なのではないか」ということでしょう．これについては，筆者も同じ意見です．しかし，コーディング規約のたぐいというものは，機械的に作って当てはめるだけですと次第に形骸化しかねません．そして最後には根拠の不明確な，単なる「おまじない」のようなものに陥る危険性があるのも事実です．たいせつなのは，ここで起こったような混乱を生じないためのしくみ作りとしてのコーディング規約作りだ，ということを念頭に置くことです（図4）．

図4　コーディング規約の検討
バラバラな記述が混乱を生んでいる場合，それぞれをどのように整理すれば混乱がおさまるかをまず検討する．この過程をスキップしていきなり規約を作ると，形骸化してしまうことは避けられない．

　そこでDさんといっしょに，上述の問題についてソース・コード規約を考えてみることにしましょう．手始めにDさんは，「定義箇所がバラバラ」なものを挙げてみました（図5）．

図5　バラバラに定義されると混乱のもとになるもの
例えば，テーブルがあちこちに存在してどこに何があるのかわからないような場合，冒頭の例で挙げたような定義ミスが起こりうる．