今回のテーマはコーディングスタイルチェックです。各言語向けに用意されているコーディング規約を紹介するとともに、コードのチェックを行ってくれるオープンソース・ソフトウェアを紹介します。見やすい奇麗なコードを書くためにもぜひ取り入れていきましょう。

[s2If current_user_can(access_s2member_level1)]

1. PHP

PHPはコーディング規約が多いように思います。

それぞれプラグインを開発したりする際には、そのフレームワークのコーディング規約に沿って開発を進めるのが良いでしょう。会社であれば使っているフレームワークに応じてコーディング規約を選定するのが良いと思います。問題は独自の規約を作ろうとしたりすることです。元々コーディング規約が存在するのであれば、車輪の再発明は不要でしょう。

2. Ruby

Rubyコーディング規約。インデント幅がスペースで二つ、改行の入れ方の規定が基本になります。面白いのはメソッド定義の中にはコメントをを記述しないというのがあります。もしコメントが必要なコードであればリファクタリングを勧めるという理由からです。

3. Perl

perlstyle - perldoc.perl.org。インデント幅は4などの基本的な記法の他、“open(FOO,$foo) || die “Can’t open $foo: $!";”よりも “die “Can’t open $foo: $!” unless open(FOO,$foo);”の方が良いでしょうといった良い書き方の勧めについても書かれています。

4. JavaScript

JavaScriptもまた規約が数多く存在します。

JavaScriptの場合、かつてのPHPのようにビューとロジック、モデルとか混ざり合い、かつプロトタイプベースであること、コールバックを使って非同期処理を行うのが基本ということもあって分かりやすく書かないとすぐにカオスな状態になるイメージがあります。この辺りは記法というよりも開発手法のようなものを参考する方が良いのかも知れません（切り出し方など）。

5. Java

さすがにJavaはエンタープライズ系で使われることが多いとあって、コーディング規約もしっかりとしています。

関連オープンソース

オープンソース・ソフトウェアを使うと機械的に規約に沿ったコーディングができているかどうか手軽にチェックできます。

1. 使われているコードのチェックもできる！Google製のJavaScriptカバレッジツール「ScriptCover」

カバレッジ率が高い＝バグがないという訳ではないですが、カバレッジ率が高ければそれだけ自分が予定しているコードを通っているということなのでバグが混入する可能性は低くなると考えられます。ScriptCoverはWebサイト向けですが、テストツールと組み合わせて使うと便利そうです。プログラミング言語においてバグを押さえ、開発効率を向上する試みは多数あります。しかし結局のところ、一番最適なのはテストすることではないでしょうか。目視でのテストは大事ですが、それだけではなく自動化できるテストの仕組みも導入を検討してください。

https://www.moongift.jp/2009/12/reek/
2. コメント量チェッカー「cloc」

clocはプログラムソースを解析し、改行やコメント、コード量などを一覧表示してくれるソフトウェアだ。対応している言語は60以上にものぼる。Java/Perl/PHP/Ruby/Python/JavaScript/HTML/C#/C/C++等の有名な言語はもちろん、ABAP/Fortran/MUMPS/Oracle Report等のマニアックなものにも対応している。 特徴的なのは、配布ファイルが一つのみと言う事。Perlでよくある、他のCPANモジュールは必要ない。Windowsにいたっては実行ファイル形式でも提供されているので、ダウンロードして即利用できる。 処理対象はファイルまたはディレクトリを一括してい可能だ。また、圧縮ファイルでも対応している。ソースコード量とコメント量を比較し、どれ位の割合になっているか分かれば、大雑把ではあるが必要な対処が打てるだろう。 こうしたチェックは常日頃から必要だ。いざとなった時、ソースを見てみたらさっぱり分からなかったでは済まされない。適切なコメント量がプログラムのバグを見つける鍵になる。

3. 潜むセキュリティ問題を事前に暴きだす「Rails Brakeman」

Rails BrakemanはRailsアプリケーションのリポジトリを読み込んでセキュリティチェックしてくれるサービスです。セキュアなプログラミングをするためのノウハウは幾つかあります。つまりそれに沿って現状のコードを確認すれば、万一のセキュリティインシデントを未然に防げるかも知れません。Railsアプリケーションについてそれを行うのがRails Brakemanです。セキュリティウォーニング、モデル、ビューのセキュリティウォーニングが出ています。

4. PHPのコーディングチェックに「Spike PHPCheckstyle」

Spike PHPCheckstyleはPHPのコードをチェックし、規約に沿って書かれているか確認してくれる。結果はHTMLファイルでレポートしてくれる。規約外の箇所があると、一覧にしてくれるので問題の有無が分かりやすい。複数のファイルも一気にチェックできる。コーディング規約にはPEARのコーディング標準が使われている。EclipseとSpike PHPCheckstyleを連携させる方法も紹介されており、実用的だ。Subversionのフック等と組み合わせても面白いかも知れない。

5. JavaScriptのコーディングスタイルをチェック「jscheckstyle」

jscheckstyleはJavaScriptのコーディングスタイルチェッカーです。JavaScriptがサーバサイド、スマートフォンアプリなどの開発でも使われるようになり利用範囲が拡大しています。そんな中、JavaScriptのコードについて一定の品質を保つために使ってみたいのがjscheckstyleです。結果は通常出力の他、HTMLやXML、JSONによる出力も可能です。XMLの場合はJavaのコーディングスタイルチェック互換でJenkinsと組み合わせて使うこともできます。その他Emacs向けの出力もサポートされています。

6. GitHubにPushする前に記法チェック「Github Preview」

Github PreviewはRuby/Sinatra製のソフトウェア（ソースコードは公開されていますがライセンスは明記されていません）です。Wikiにしても同様ですが、HTMLを直接書くのは苦手にしている人にとって特定の記法に沿って書くことで自動変換してくれる仕組みというのは便利です。ただし記法を覚えるというのは相当な負担になります。特に書いて間違っていたりすると大きなストレスになってしまうでしょう。それを防ぐためには入力補助が有効です。WYSIWYGなエディタをつける（しかし大抵これが嫌で記法を使っているのですが）、リアルタイムプレビューをつける、記法のヘルプを表示すると言った具合です。いずれの方法が有効かは利用者のリテラシーによって異なるでしょう。

7. Rubyのリファクタリングのお供に「flay」

flayにファイルを渡すと内部を解析し、似たような箇所をリストアップしてくれる。結果はスコアにしてくれる。0が最も低い（重複していそうな箇所がない）数字で、上がっていくごとに重複が散見されるようになる。ディレクトリ全体で行えば複数ファイル間のチェックも行われる。差分を表示する機能もあるので重複しているとおぼしき部分も見つけやすい。事前にユニットテストを書いておいてエラーが出ない状態にしつつリファクタリングを進めればDRYに沿った奇麗なコードになっていくだろう。バグを減らすためにも取り組みたい施策の一つだ。

10. JavaScriptのコードを解析して型を明示する「Doctor JS」

Doctor JSはJavaScriptのソースコードを静的に解析し、関数の返却値の型を表示する。全てのコードを解析できるという訳ではないが、functionが順番に定義されているようなファイルである必要があるようだ。jQueryやPrototype.jsのようなコードは解析に失敗した。通常のfunctionを書く場合はもちろん、それ以外にもPolymorphism/Prototypes/Exceptions/Callbacksなどの書き方に対応している。返り値の型が分かれば、それに合わせて検証したりプログラミングができるようになる。作る側も適切に解析されるような記述ができるように心がければ、よりミスの少ない作りになりそうだ。自分のコードで一度試してみると面白そうだ。node.jsを使っているということは、解析にv8エンジンのものを使っているのかもしれない。元々Doctor JSはMozilla Labsからリリースされているものなので、JagerMonkeyが使われているのかと思ったが、そうではなさそうだ。

まとめ

良いコーディング規約とは、束縛は強くなく奇麗なコードが一定の品質で作れるように目指すべきです。また、プログラマーがどう書くべきか悩むような所がないようにしておくと開発がスムーズになります。良くないと思うのは自社オリジナルのコーディング規約の策定です。そういったものは車輪の再発明になりがちですし、初期の作成はよくともメンテナンスが滞りがちで徐々に矛盾が生じていきます。であれば既に外部にある有名なコーディング規約を採用する方がメリットがあるはずです。

なおコーディング規約に沿った奇麗なコードであるからと言って不具合がなくなる訳ではないので注意が必要です。ただし不具合の率は個々人が自由気ままに記述している時に比べるとずっと減るのではないでしょうか。

[/s2if]