プログラミングのお作法

4月になると新入社員が入社してきますが、なかなか難しいのが「お作法」のことです。

大規模なシステム開発ではお互いの意思疎通ができていないと作業が進みません。部品と部品とがつながらない、ですとか予想外のデータが渡されてしまう、という根源的な問題はきちんと設計書を作っておけば回避できる問題です。しかしながら現実には設計書だけでは回避できない問題もあります。

例えばメンバーの入れ替わりが激しく、何人かで1本のプログラムを作るということがあります。極端な例で言うとまずAさんが基本的な機能を作成し、動作するようになるまでBさんが修正し、単体テストレベルの厳密なエラー処理をCさんが行い、結合テスト段階での不具合をDさんが修正する、というような場合です。

お互い開発のプロとしてそれなりの技量を持っていますが、他人が作ったプログラムを引き受けるのはやはりやりづらい作業です。こういう場合、変数の使い方のルールなどを「コーディング規約」として掲げておくと便利です。例えば変数では一文字変数を禁止する（i,j,kなど）、名前を英語または日本語で統一する（intSum,intGoukeiなど）、接頭語を統一する（int,Lngなど）などを行えば変数が意味する内容を理解しやすくなります。（自分が作ったプログラムすら再読できないのは問題外ですが。）

ところがあまりにも膨大なコーディング規約を作成すると、誰もその全容を理解できなくなってしまいます。せめて「これは規約でルールが決まっていた気がする」というくらいの印象が残る量で無ければ、それぞれの条項を遵守する事も現実的ではなくなってしまいます。となるとあまりにも基本的なことはコーディング規約に掲載されなくなり、「普通こうするだろ」という暗黙の了解は「お作法」という名前の不文律と化します。

その組織がどこまでをコーディング規約に載せるかによってお作法と化すかどうかは変わります。誰もが「これはお作法だろ」と思うものは想像し難いのですが、こういった感じで伝わりますでしょうか。（私の思いつきです。弊社の規約とは関係ありません）

• Const定数は各プログラムに分散させないで記述場所はまとめる
• 引数が4個以上になるならクラスを作って1個の引数とする
• If文の条件でNotを使わずにElseで表現する　←　私の好みです。
  if A=B then
       '　何もしない
  Else
       hoge()
  End IF

プログラムの実行場所となるハードウェアは最近ますます性能がよくなっています。一般的な企業向けの情報システムを開発する現場では「メモリの1バイトは血の一滴と思え」と言われる機会などほとんどないのではないでしょうか。そう言ったところではメモリの節約のために技巧的なプログラムを書くよりも後々のメンテナンス性を考えたシンプルでわかりやすいプログラムが好まれるでしょう。もちろんメモリリークを起こすようなプログラムを書かれては困るのですが、近年の親切な言語ではメモリリークを低減してくれる機能があるものもあります。

むしろそういう言語からプログラミングの習得を学び始めた世代からしたら「1バイトが血の一滴ってSDRAMのバイト単価いくらだと思ってんだ」とか「自分で解放するよりも実行基盤に任せたほうが正確で早い」とか先輩の常識を否定するような発言が飛び出るかもしれません。大切な事は伝えなくてはなりませんが、時代の変化を無視して自分の常識を「お作法だ」と押し付けないようにしたいものです。

# そういう自分は趣味プログラマの出身で1人コーディングの期間が長かったためにソースの読みやすさには自信がありません。悪い見本とならないよう精進したいと思います。