新人技術者のためのロジカル・シンキング入門（5） ―― ソース・コード規約の作り方
ここでは，コーディング規約について考える．コーディング規約（コーディング工程での管理方針）を定めておくことで，ソフトウェアの不ぐあいの発生をある程度抑えられる．ただし，関数や論理値の正負の定義，データ構造などをよく検討しないで規約を作ってしまうと，形骸化してしまう．単なる「おまじない」にならない規約の作りかた，そして規約の運用にあたっての考えかたを解説する． （編集部）
技術解説・連載「新人技術者のためのロジカル・シンキング入門」 記事一覧
第1回 いかにしてバグの原因を突き止めるか
第2回 プログラミングにおける良いデータ構造
第3回 「必要とされる設計書」の作り方
第4回 直したバグがゾンビのごとく復活する
第5回 ソース・コード規約の作り方
第6回 ハードウェア基礎の基礎
第7回 「ひたすら流すだけのテスト」にさよなら
第8回 CPUの演算量をひたすら削る
第9回 メモリ転送速度の最適化設計
第10回 「工学の知」を実務に生かす
●お知らせ
本連載記事を元に加筆・再編集した書籍『組み込みエンジニアのためのロジカル・シンキング入門』が好評発売中！
Dさんがリーダをつとめるプロジェクトは，1週間ほど前にリリースを終えたばかりです．ホッとしたのもつかの間，しごとを終えて帰宅しようとしたDさんのところに，リリース先のメーカに勤めているQさんから電話がかかってきました．リリースされたモジュールを組み込んだところ，正しい結果が得られず，ときどきシステムがハングアップするというのです．
まずDさんは，モジュールといっしょに提供したリリース・ノートを先方に確認してもらうことにしました．そして，わかりにくい点などを解説してみましたが，いずれも問題なく組み込んだはずだという答えが返ってきました．そこでDさんのプロジェクト・サーバに保管されているモジュールを動かしてみたのですが，先方が指摘するような現象は再現できません．
手詰まりになったDさんは，リリース先のQさんの会社におじゃましてモジュールの組み込み状況を見せてもらうことにしました．しかし，モジュールの引き数の渡しかたなどを見ても異常はみられません．「もしや，なんらかの処理系のバグかな」と思いかけたDさんの目に偶然飛びこんできたのは，ライブラリの呼び出し元である親ルーチンのソース・コードに書かれていた図1のような記述でした．
図1 処理系バグに思えたエラーの正体
リリース先で組み込み元のソース・コードを見ると，ライブラリ内部の記述と似たようなものが見つかった．こうしたものがあれば，リンク・エラーを起こすはず．起こさなかったということは...．テーブルだけ組み込まずにリリースしたというオチ．
「あれ，おかしい．このテーブル注1は32ビット幅のはずだ．short型では正しく動かないんじゃないのか...．というか待てよ．そもそもこんな記述が呼び出し元にあるのに，なんでリンク・エラーが起きないんだ？」．
注1：中身を書き換えず，プログラム起動時からの値が固定で用いられる配列のことをテーブルと呼ぶ．
不安に思ったDさんは，プロジェクトのメンバに電話して，リリースしたソース・コードをもう一度確認してもらえないかと連絡してみることにしました．30分後に返ってきた答えは信じられないものでした．
「リリース前に使っていたテスト用関数のファイルにテーブルの実体をまちがえて書いてしまっていた．そのため，リリースしたライブラリにはこのテーブルの実体は含まれていない」．
なんと，ライブラリの中に含まれているべきテーブルの実体がリンクされていなかったというのです．しかも，たまたま呼び出し元で同名のテーブルがあったためにリンク・エラーを起こさなかったので，リリース先でも気づかなかったということでした．
