# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
4．コーディング規約を自動化する フィリップ・ヴァン・ラーネン (Filip van Laenen)
あなたも見たことがある光景かもしれませんが，
新しいプロジェクトが立ち上がる時というのは，
皆，「強い抱負」を持つものです．
ああもしよう，
こうもしよう，
と希望に燃えるのです．
そういう抱負は，多くの場合ドキュメントにまとめられます．
例えば，
「このプロジェクトでは，一定の規約に従ってコーディングをする」
ということが決定され，
その規約がドキュメントにまとめられたりするのです．
キックオフミーティング*1では，
プロジェクトリーダーがドキュメントの内容を承認し，
プロジェクトのメンバーの多く，
時には全員が，
その規約を守ることに賛成します．
しかし，
いざプロジェクトが開始されると，
こういった最初の抱負は徐々に顧みられなくなっていきます．
そしてプロジェクト完了時には，
規約などまったく無視された無秩序なコードが，
なぜそうなったのか誰も理由がわからないまま，
納品されてしまうのです．
一体，どこでおかしくなってしまったのでしょうか？
おそらく，すでにキックオフミーティングの時点でおかしくなっていたのだと思います．
プロジェクトチームの中に，
実はコーディング規約に無関心な人や，
なぜ規約が必要なのかを理解していない人がいたのでしょう．
もっとひどい場合には，
内心まったく規約には賛同しておらず，
初めから守らずに作業するつもりでいた人もいるかもしれません．
規約には賛成で，必要な理由もわかっていたけれど，
納期に間に合わせなければ，というプレッシャーに負けて，
守ることをあきらめた，という人もいるかもしれません．
規約に従い「美しい」コードが書けても，
高機能を求める顧客の関心を得ることはできません．
それに一定の規約に従って，コードを書くというのは，
自動化しないかぎり，かなり面倒なことです．
クラスのインデントを整え，
見やすく混乱しにくくするというだけでも，
手作業でやろうとすると意外に大変なことは，
自分でやってみればすぐにわかります．
では，そういう問題がありながら，
そもそも何故，コーディングに規約を設けるべきなのでしょうか？
その理由の1つは，
「誰も，自分の書いたコードを『私物化』できないようにすること」
です．
皆が，自分の担当の部分のコードを好き勝手な形式で書くと，
どうしてもその箇所はその人のコードになってしまいます．
逆に，どの箇所も均一な形式で書いてあれば，
私物化という事態にはなりにくくなるでしょう．
その他，開発者がアンチパターン*2を使ってしまうことで生じる，
ありがちなバグを防ぐという目的もあります．
コーディング規約に従うことで，
プロジェクト全体としての進行を円滑にし，
開発速度を一定に保ちやすくします．
ただし重要なのは，
プロジェクトに参加する全員が，
同じ規約に従わなくてはならないということです．
他の開発者が皆4タブのインデントを使用しているのに，
一人だけ3タブのインデントを使用していては，
意味がありません．
コーディング規約の順守に役立つツールは多数存在します．
そうしたツールには，
規約をドキュメント化する機能，
規約からの逸脱を報告する機能などがあります．
ただし，そうゆうツールを使えば問題がすべて解決するわけではありません．
コーディング規約は可能な限り，
自動的，かつ強制的に守られるようにするべきでしょう．
具体的には以下のような方法が有効です．
・コードの整形処理をビルドプロセスに含めてしまう．
コードのコンパイルをする度に，誰もが必ず，自動的に整形することになる．
・静的なコード解析ツールを使用してコードを解析し，
望ましくないアンチパターンがないかを探す．
もし見つかれば，ビルドを中止する．
・ツールの設定により，プロジェクト固有のアンチパターンも見つけ出せるようにする．
・テストカバレッジ*3をただ計測するだけで終わらせるのではなく，
計測結果の判定も自動的に行われるようにする．
そしてテストカバレッジが低すぎる場合には，
ビルドを中止する．
以上のことを，重要なプロジェクトでは必ず実践するようにするのです．
ただし，守るべき規約が，
すべて自動的に守られるような仕組みを作ることはほぼ不可能でしょう．
警告や修正を自動化できないルールがある場合には，
自動化の仕組みに加えて，ガイドラインの整備が重要になってきます．
とはいえ，この場合には，
自分を含め，チームのメンバー達は，
おそらく規約を忠実には守らないだろうと考えておくべきです．
もう一つ重要なのは，
コーディング規約は固定的ではなく，
変化すべき，ということです．
プロジェクトを進めていけば，
そのプロジェクトで求められるものも変わってきます．
初めのうちは懸命だと思えていたことが，
数カ月後にはそうでなくなっている，
ということもあるのです．
■著者データ
[フィリップ・ヴァン・ラーネン (Filip van Laenen)]
ノルウェーの公営企業，民間企業に
ITソリューションを提供するソフトウェア企業，
Computas AS社のチーフエンジニア．
ソフトウェア産業において，
10年以上の経験を持ち，
大小様々な開発チームの一員として開発プロジェクトに携わったこともあれば，
リードディベロッパ，あるいは技術リーダとして，
一社のソフトウェアエンジニアリング事業，
あるいはセキュリティ事業を統括したこともある．
そうした実績を積む中で，
Smalltalk,Java,Perl,Ruby,PL/SQLなどの
多数のプログラミング言語を使用してきた．
コンピュータセキュリティや暗号技術にも関心を持ち，
Computas社で何年にも渡り，
CSO(Chief Security Officer:最高セキュリティ責任者)
の地位にあった．
ルーベンカソリック大学で，
電子工学の理学修士号，コンピュータ科学の理学修士号を取得，
元はフランダースの出身だが，
1997年にノルウェーに移住し，家族と共にオスロのコルサスで暮らす．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:プロジェクトの開始を宣言するための集まりを指す．キックオフミーティング とは | プロジェクトマネジメント関連用語集 | ミツエーリンクス
*2:ある問題に対する、不適切な解決策を分類したものアンチパターン - Wikipedia
*3:テストがどれだけすべての機能を網羅(coverage)しているかを示す指標 Software Testing - Columns: テストカバレッジ
