【OS開発よもやま話】命名規則からは例外をなくせ

今日は、ソフトウェアエンジニア向けの記事です。
それ以外の方はすみません。(^^;
単なる開発の思い出話ですが、何か教訓が得られればと思います。

今回は、OS を開発していたときの話から・・・

---

優秀な開発チームほど、命名に気を遣います。
それには色々な理由があります。

• 統一されたソースコードやドキュメントを書きたい。

• より簡潔に情報を伝達したい。

• ヒューマンエラーを減らしたい。

これはこれで、非常によい事なのですが、マネジメントの視点を入れておかないと、意外な落とし穴にはまってしまいます。

タコ部屋に集められて

2009 年頃、私は OS 開発チームの所属になりました。
当時は、まだ Kernel の設計や Bootloader の実装などが行われている段階で、少人数が倉庫のような部屋（通称：タコ部屋）に集まって仕事をしていました。

素材提供：Adobe Stock

そこで仕事の合間に話し合われていたのが「命名規則」でした。

◎命名規則の強さに注意

命名規則、及びそれらを含んだコーディング規約というものは、成果物の性質によって 強さ が変わってきます。

使い捨てのソースコードに命名規則は必要ありませんし、
外部に公開しないソースコードの命名規則は緩くても問題ありません。

しかし、このとき私たちが開発していたのは

• 継続的に利用される

• 多人数での開発になる

• API を外部に公開する

という性質のものであったため、命名規則やコーディング規約を厳しいものにする必要がありました。

素材提供：Pixabay

【駄文】
後々に、参加してきた協力会社の一人が規約違反を指摘されたところ、
「古い会社は、おかしなルールが多いですね」
という発言をしてきました。
この一言だけで、”彼は経験の浅い素人だ” という評価になりました。
決して、自分の経験のみで 規約の強さ を判断してはいけないのです。

◎命名規則の例外をどうするか？

タコ部屋に時を戻します。

私がチームに参入したとき、すでに以下のようなことは決まっていました。

• 単語の省略は禁止。（Initialize を Init とするのはダメ）

• 語順は英文法に従う。

• Manager という単語は使用は禁止。（全て Controller に統一）

• Pascal case を採用する。 ※以下を参照

GetFileName   // Pascal case（upper camel case）
getFileName   // camel case（lower camel case）
get_file_name // snake case

しかし、開発メンバーが悩んでいた項目がひとつありました。
それは「すべて大文字で構成されている単語はどうするか？」という問題です。
例えば、DVD や NAND といった単語です。

「二文字までの単語は大文字ではよいのでは？」（CD とかは OK）
「Wikipedia に大文字で書いてあったら OK にすれば？」
「その都度、話し合えばよいのでは？」

など、色んな意見が出ていました。

素材提供：Adobe Stock

しかし、私の提案は一択でした。

「例外なく先頭の文字のみ大文字にする」

理由は簡単です。

開発の後半では、例外を検討している時間なんてない

大規模開発ではマネジメントコストも考慮せよ

私は、その前の会社で大規模開発を経験していました。
マネジメントコストが跳ね上がることは、おおよそ予想がついていました。

このときは、私の案が採用されました。
そして一年後、開発メンバーのひとりが「その通りだったね」と言ってきました。
・・・クソほど忙しくなりました。(^^;

素材提供：Pixabay

開発現場における規則や規約は「分かりやすく、管理もしやすい」ものにした方が、判断に時間を取られませんし、判断基準にブレも出ません。

兎に角、現場の人間には熟考しなければならないことが多いので、命名規則からは例外をできる限り排除した方がよいのです。