コーディング規約を自動化する – プログラマが知るべき97のこと

You’ve probably been there too. At the beginning of a project, everybody has lots of good intentions — call them “new project’s resolutions.”

あなたも見たことがある光景かも知れませんが、新しいプロジェクトが立ち上がる時というのは、皆「抱負」を持つものです。ああもしよう、こうもしよう、と希望に燃えるのです。

Quite often, many of these resolutions are written down in documents.

そういう抱負は､多くの場合ドキュメントにまとめられます。

The ones about code end up in the project’s coding standard.

たとえば｢このプロジェクトでは、一定の規約に従ってコーディングをする」ということが決定され、その規約がドキュメントにまとめられたりするのです。

During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them.

キックオフミーテイングでは、プロジェクトリーダーがドキュメントの内容を承認し、プロジェクトのメンバーの多く、時には全員が、その規約を守ることに賛成します。

Once the project gets underway, though, these good intentions are abandoned, one at a time.

しかし、いざプロジェクトが開始されると、こうした最初の抱負は徐々に顧みられなくなっていきます。

When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way.

そしてプロジェクト完了時には、規約などまったく無視された無秩序なコードが、なぜそうなったのか誰にも理由がわからないまま、納品されてしまいます。

When did things go wrong?

一体、どこでおかしくなってしまうのでしょうか。

Probably already at the kick-off meeting.

おそらく、すでにキックオフミーティングの時点でおかしくなっていたのだと思います。

Some of the project members didn’t pay attention. Others didn’t understand the point.

プロジェクトチームの中に、実はコーディング規約に無関心な人や、なぜ規約が必要なのかを理解していない人がいたのでしょう。

Worse, some disagreed and were already planning their coding standard rebellion.

もっとひどい場合には、内心まったく規約に賛同しておらず、はじめから守らずに作業をするつもりでいた人もいるかもしれません。

Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go.

規約には賛成で必要な理由もわかっていたけれど、納期に間に合わせなくては、というプレッシャーに負けて、守ることをあきらめた、という人もいたでしょう。

Well-formatted code doesn’t earn you points with a customer that wants more functionality.

規約に従い「美しい」コードが書けても、高機能を求める顧客の歓心を買うことはできません。

Furthermore, following a coding standard can be quite a boring task if it isn’t automated.

それに、一定の規約に従ってコードを書くというのは、自動化をしない限り、かなり面倒なことです。

Just try to indent a messy class by hand to find out for yourself.

クラスのインデントを整え、見やすく混乱しにくくするというだけでも、手作業でやろうとすれば意外に大変なことは、自分でやってみればすぐにわかります。

But if it’s such a problem, why is that we want to have a coding standard in the first place?

では、そういう問題がありながら、そもそもなぜ、コーディングに規約を設けようなどと思うのか。

One reason to format the code in a uniform way is so that nobody can “own” a piece of code just by formatting it in his or her private way.

その目的の1つは「誰も、自分の書いたコードを『私物化』できないようにする」ということです。皆が、自分の担当部分のコードを好き勝手な形式で書くと、どうしてもその箇所はその人のコードになってしまいます。逆に、どの箇所も均一な形式で書いてあれば、私物化という事態にはなりにくいでしょう。

We may want to prevent developers using certain anti-patterns, in order to avoid some common bugs.

その他、開発者がアンチパターンを使ってしまうことで生じる、ありがちなバグを防ぐという目的もあります。

In all, a coding standard should make it easier to work in the project, and maintain development speed from the beginning to the end.

コーディング規約に従うことで、プロジェクトの全体としての進行を円滑にし、開発速度を一定に保ちやすくします。

It follows then that everybody should agree on the coding standard too — it does not help if one developer uses three spaces to indent code, and another one four.

ただし重要なのは、プロジェクトに参加する全員が同じ規約に従わなくてはならないということです——他の開発者が皆4タブのインデントを使用しているのに、1人だけ3タブのインデントを使ったのでは意味がありません。

There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standard, but that isn’t the whole solution.

コーディング規約の遵守に役立つツールは多数存在します。そうしたツールには、規約をドキュメント化する機能、規約からの逸脱を報告する機能などがあります。ただし、そういうツールを使えば問題がすべて解決するわけではありません。

It should be automated and enforced where possible. Here are a few examples:

コーディング規約は可能な限り、自動的、かつ強制的に守られるようにすべきでしょう。具体的には次のような方法が有効です。

Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.

コードの整形処理をビルドプロセスに含めてしまう。コードのコンパイルをする度に、誰もが必ず、自動的に整形することになる。

Use static code analysis tools to scan the code for unwanted anti-patterns. If any are found, break the build.

静的なコード解析ツールを使用してコードを解析し、望ましくないアンチパターンがないかを探す。もし見つかれば、ビルドを中止する。

Learn to configure those tools so that you can scan for your own, project-specific anti-patterns.

ツールの設定により、プロジェクト固有のアンチパターンも見つけ出せるようにする。

Do not only measure test coverage, but automatically check the results too. Again, break the build if test coverage is too low.

テストカバレッジをただ計測するだけで終わらせるのではなく、計測結果の判定も自動的に行われるようにする。そしてテストカバレッジが低すぎる場合は、ビルドを中止する。

Try to do this for everything that you consider important.

以上のことを、重要なプロジェクトでは必ず実践するようにするのです。

You won’t be able to automate everything you really care about.

ただし、守るべき規約がすべて自動的に守られるような仕組みを作ることはほぼ不可能でしょう。

As for the things that you can’t automatically flag or fix, consider them to be a set of guidelines supplementary to the coding standard that is automated, but accept that you and your colleagues may not follow them as diligently.

警告や修正を自動化できないルールがある場合は、自動化の仕組みに加えて、ガイドラインの整備が重要になってきます。とはいえこの場合は、自分を含めチームのメンバーたちが、おそらく規約を忠実には守らないだろうと考えておくべきでしょう。

Finally, the coding standard should be dynamic rather than static.

もう1つ大切なのは、コーディング規約は固定的ではなく、変化していくべき、ということです。

As the project evolves, the needs of the project change, and what may have seemed smart in the beginning, isn’t necessarily smart a few months later.

プロジェクトが進行していけば、そのプロジェクトで求められるものも変わってきます。はじめのうちは賢明と思えたことが数ヶ月後にはそうでなくなっている、ということもあるものです。