C言語のソース実装
id:minekoaさんの以下のエントリーを読んでつらつらと。
一時期、何でもかんでも巨大なライブラリアーカイブ(.a,.lib)に放り込むというコーディングスタイルを持っていた時期がありました。
結構いろんなメリットがあって、
- ライブラリ自体が巨大でも、ライブラリ内のモジュール依存性が低いと実際にリンクされるのは一つだけ。
- C言語はエントリーポイントを一つしか持てないので、ユニットテストがやりづらいのを切り分けられる(本番時もmain関数のみのソースをリンクするのみ)
- コンパイルの時間が省略される
まぁ、生でC言語を触ることが極端に減ったのでこの辺の好みは今となってはあまり生かされていないのですが、他にもこんな方針を同時に立てていました。
- 関数は１画面以内。それも、中括弧はGNUスタイルの改行で(可読性のため)
- インデントが嵩んでコードが右端にたどり着いたらそこから内側は別の関数に(可読性のため)
- 1ソース4KByte以内(コンパイルの粒を小さくしてmakeの依存対象を減らす。落ちた可読性はCTAGで補う)
- ヘッダも可能な限り分ける。機能の外部からのインターフェースと機能内でのみ使用する関数/大域変数は別のヘッダで(コンパイルの粒を小さくしてmakeの依存対象を減らす)
まぁ、この辺は師匠から教わった物がほとんどで、一つ一つの理由を聞く度にえらく感心した物でした。
で、別れて数年たったあとで、ひさーしぶりに師匠に会いました。
「いまでも教わったコーディングスタイルでずっとやってますよ」
「へ？ まだあれにこだわってたの？」
「何か問題でも？」
「いや、別にいいんだけどさ。今時のコンパイラはインクリメンタルコンパイルが強力だから、再ビルドの手間を考えるとソース分けても無駄だよ」
そんなぁ(^^;)。
まぁ、実際にはインクリメンタルコンパイルのある素敵環境ばかりでもありませんし(当時組み込みが多かったので全般的にコンパイラがしょぼかったの)、リッチ環境はいいなぁと指をくわえて見てましたが。
デバッグのためのターンアラウンドタイムを減らすと開発効率が劇的に上がるのはSmalltalkのような変態環境や、すっかりSmalltalkもどきになってきたEclipse（Javaはそもそもリンクしないし）やVisualStudio（これまたインクリメンタルコンパイルがかなり強烈）を見ていても判るとおりですので、リビルドにかかる時間はこの際さておくとしても１回のリンクまでの時間が短いに越したことはないのは自明です。リンク自体にかかる時間はどうせ固定ですのでそれより前のコンパイル/アセンブル時間をmakeによる依存性チェックで減らせるのならそれに越したことはないだろうとは思います。
とはいえ、巨大なプロジェクトの統合テストやシステムテストは……どうにもならないかなぁ(^^;)。上がってきたモジュールがいつ、どうかき替えられたか判らない以上リビルド必須でしょうし……。
