Entry

コーディング規約つれづれ

2009年06月28日

少し前の話だけれども,/.J より。この手の話にネタは尽きないわけですが。

/.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか?逆に規約のせいで問題が起きてしまったケースなどあるだろうか?他にも、使える「自分ルール」などもあれば是非。

いいコーディング規約、悪いコーディング規約?

いいコーディング規約は,大抵意識しなくても準拠するもんなので,普通は悪い(と思われる)コーディング規約が目に付くんだと思います。あたしが見た規約の中でやだなぁ,と思ったのはこゆもの。引用先とかぶってるのもあるけれど。ちなみに,以下は自社内の規約ではありません。受託では客先の規約に従ってコーディングすることが多いので,そのときに見た規約。

  1. 修正したらコメントに修正日や修正者の名前を書くこと。
  2. 静的型付け言語でハンガリアン記法。
  3. Javadoc/Doxygen のようなツールとは無縁のコメント規約
  4. C++ では例外の使用禁止。
  5. C++ では参照の使用禁止。
  6. C++ ではコピーコンストラクタの使用禁止。
  7. C++ では代入演算子の使用禁止。
  8. C++ では名前空間の使用禁止。
  9. C++ ではテンプレートの使用禁止。
  10. C++ のメンバ変数の名前は,頭にアンダースコア(_)を入れる。
  11. OOP 言語のメンバは,変数/メソッドを含め,すべて public で。
  12. インデントはタブで。

2. についてはちょっと微妙で,個人的に静的に型付けされる言語(Java とか C/C++ とか)については,基本的にハンガリアン記法を使わない方がいいと思っています。型安全については,書かなくてもコンパイラが検出してくれますから。lpszBuffer とかって,無駄に長くなるのもなんだかなぁ……と。Windows のプログラムのときには合わせますけど,あれは純粋な C/C++ というよりは,Windows C/C++ のようなカテゴリにあるもんだと思っていたりします。メソッド名も Pascal 調だし。

一方,例えば Perl なんかの場合,$a + $b と $a . $b のどっちが正しいのか,その文だけだと判断できません。$strA + $strB とあったら,何か間違えてそうだ,と分かるので,こゆのはハンガリアン記法にしたほうがいいと思う。こう考える人は少ないかもしれませんけど。

続いて,「C++ のメンバ変数の名前は,頭にアンダースコア(_)を入れる」なんですけれど,これを採用しているところは,割と多いと思います。あたしはお尻にアンダースコア派なので,これはちと嫌だ。頭にアンダースコアが付いた名前は,上位の規約で API の名前やコンパイラの組み込みの名前になっていることがあるので,かち合うかもしれないからです。Windows のクラスでは m_ を付けるけど,ハンガリアン記法と同じで冗長だと思っています(Windows のプログラムでは合わせるけど)。

それと,最後の「インデントはタブ」ってのも,むしろこっちの方が多数派なんじゃないかと思います。これは自社内の規約もそう。ただ,エディタによって見え方が変わるのは個人的にはいただけない。

最後に,C++ 関連なんですけど……C++ の便利機能を(クラス以外)すべて骨抜きにする規約に当たったことがあります。もうね,これ C なんじゃないか,と。特に例外禁止については困ったちゃんで,C++ のメソッドでエラー時に NULL を戻す危うさにビクビクしながらコーディングしてました。NULL 参照したら,一発でシステム例外なわけで,例外をプログラム内で収束できない恐れがあるところが怖い。

で,そもそも論。

ってか、コーディングで規約が必要なコーダーを前提にしているのが問題では? ましなのを雇えよ...とか思う。

わけわからんコード吐いた時点で職場変えさせたらよいのでは?
それは「職場を変えさせる」側の技量もからむから怖くて出来ないってことなのかもしらん。

いいコーディング規約、悪いコーディング規約?

しかし,これは違うと思う。

上の C++ の規約なんかをはじめとして,こゆ規約は,コードレビューの責任者なり保守の責任者なりのスキルに合わせているんだと思います。つまり,「俺が読めないコードを書くな」と。実際に会っていないから分からないけれど,上の C++ の規約を作った責任者さんは,きっと C しか知らない人だったんだと思う。

コーディング規約は,確かにソフトウェアの品質を一定に保つ効果があるし,多くの場合保守性も高まります。個々人が勝手なコーディングをしていると,それぞれがどんなに立派なポリシーを持っていたとしても,保守が大変になる。つことで,こゆのは書く側にとっては「従うもの」で,読む側や管理する側(将来の自分も含む)に合わせた体裁なんですね。だから,仮に規約の内容が「わけわからんコード」を作るモノで,個々人が勝手に書くコードの方が可読性や効率において優れていたとしても,全体として一貫している前者の方が規約として立派に成立することになる。で,こゆ規約は個々のコーディングメンバーのうちで一番低い水準に合わせているというよりは,社内なり受託先なり全体の水準に合わせられていたりする。なにせ,そもそも規約を作るのは,大抵技術責任者なり保守担当の人ですしね。

つことで,コーディング規約は,その会社なりプロジェクト責任者なりの技術水準が分かっちゃうという便利な指標でもあるのでした。就活中の学生さんなんかで,会社選びに悩んでいる方は(いまどきそゆ人は少ないだろうが),「コーディング規約を見せてください」とでもお願いしてみるといいかも。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN