1年目から身につけたい! チーム開発 6つの心得

第2章 コーディングスタイルを統一しよう―理解しやすく変更に強いコードの第一歩

この記事を読むのに必要な時間:およそ 4 分

ツールの助けを借りて統一しよう

コーディングスタイルを統一するためには,テキストエディタ注6の力を借りることができます。

プログラミング向けのテキストエディタには,次のような機能があります。もちろんEclipseやVisual StudioのようなIDEIntegrated Development Environment統合開発環境)に組み込まれたエディタにもそのような機能があります。

  • ソースコードを読みやすく色付け表示する
  • 自動的にインデントをそろえる
  • 長い名前を自動的に補完する
  • リファクタリング注7を支援する

テキストエディタを適切に設定すれば,統一したコーディングスタイルでコードを書くことができます。

また,言語によってはコーディングスタイルを確認したり統一したりするためのツールが提供されていることもあります注8)⁠⁠コーディング規約チェックツール」といったキーワードで検索してみてください。

注6)
ワードプロセッサ(ワープロ)のように書式が整った文書を作るためのソフトウェアに対して,テキストの内容を効率良く編集することに特化したソフトウェアをテキストエディタと言います。
注7)
プログラムの最終的な動作結果を変えずに,内部をきれいに直すことです。
注8)
たとえばJavaScript(ECMAScript)ではESLintなどが知られています。

既存のコードは少しずつスタイルを統一しよう

現在,手元にコーディングスタイルがそろっていないコードがあるときにはどうすればよいでしょう。一度にすべて修正してしまいますか? それとも諦めてしまいますか?

コーディングスタイルがばらばらのコードのスタイルを統一するためには,ツールを使って改行位置やインデント幅を揃えたり,正規表現を使って一括置換したりといった方法が考えられます。しかし,⁠プロジェクトでの名前づけはスネークケースだが,使っているライブラリの名前づけがキャメルケースである」⁠内部の名前づけはキャメルケースだが,公開しているAPIはスネークケースである」などのように,複数のスタイルが混在せざるを得ない場合もあります。このような物まで一度にすべて修正してしまうと機能が壊れてしまいますので,スタイルの修正は慎重に進める必要があります。変更個所をカバーした自動テストがあれば一度にすべて修正しても問題がないことを確認できますが,残念ながら,⁠自動テストが整備されているのにコーディングスタイルは統一されていない」プロジェクトというのは筆者は見たことがありません。

こんなとき,筆者は次のようなやりかたを取っています。少しずつ着実に進められると同時に,無用なリスクを冒さないやりかたなので,みなさんも参考にしてください。

  • まずコーディングスタイルを決める
  • 新しく書くコードは新しいコーディングスタイルで統一する
  • 既存のコードを変更するときは,まずファイル単位で新しいコーディングスタイルに移行する。コーディングスタイルの修正が完了してから,バグ修正や機能追加をする
  • 完全を求めない
  • 設計の変更を伴うようなリファクタリングは控える

コーディングスタイルを決める

コーディングスタイルを決めるときは,インターネットで公開されていてよく使われているものから自分たちに合うものを選ぶとよいでしょう。前出のWikipediaの記事などを参考にしてください。

また,公開されているコーディングスタイルをそのまま使うのではなく,自分たちの現実に合うようにアレンジすることも必要です。たとえば,Linux Kernelのコーディング規約では次のように書かれています。

Do not unnecessarily use braces where a single statement
will do.

if (condition)
    action();

and

if (condition)
    do_this();
else
    do_that();

if文で実行する内容が1ステートメントの場合は波括弧を省略せよ,というルールです。しかし自分たちのプロジェクトではif節の波括弧は省略しないほうがよいという意見であれば,⁠Linux Kernelのコーディング規約には基本的に従うが,if節の波括弧は省略しない」というふうにアレンジしてもかまいません。

コーディングスタイルを統一してから変更する

新しく書くコードはもちろん決めたコーディングスタイルに統一して書きますが,問題になるのは既存のコードです。

既存のコードを変更するときは,まず変更する個所が含まれているファイル単位で新しいコーディングスタイルに移行し,そのあとでもともとやろうとしていた修正や機能追加などの変更を行いましょう。これは,変更によって問題が発生したときに,問題の原因となった変更個所を特定しやすくするためです。

また,コーディングスタイルを統一する際は,ルールを1つ適用するごとにコミットを分けることも大切です。たとえばインデントのルールと名前付けのルールの両方が統一されていない場合でも,⁠インデントの修正」「名前付けの修正」というふうにルールを1つ適用するごとにコミットしましょう。これも,問題の原因となった変更の特定を容易にするためには大事なことです注9)⁠

注9)
具体的にどのようにコミットするかは,第5章も併せて参照してください。

完全を求めない

コーディングスタイルの統一が重要だと書いておきながら矛盾するようですが,完全であることを求めないのも重要です。

既存のコードを修正するとき,完全にコーディングスタイルを統一しようとすると,とても大変です。インデントや括弧の付けかたの統一は問題なく適用できる場合が多いですが,名前の付けかたなどのようにコードの字面を変更するルールを完全に適用しようとすると,ツールのサポートがあっても非常に手間がかかります。ですので,そのような変更については重要度を決めて,重要なものから順に適用していくのがよいでしょう。

大規模なリファクタリングは控える

最後に,コーディングスタイルの修正はコーディングスタイルの修正のみにとどめて,それ以外の大規模なリファクタリングは控えるのも大切です。

コーディングスタイルが統一されていない状態から統一された状態になってくると,コーディングスタイル以外の粗に気づくかもしれません。しかし,設計の変更を伴うようなリファクタリングは修正範囲が広くなることが多く,ときには複数モジュールに渡る大規模な変更となる場合すらあります。また,変更時の見落としが原因で正常に動作しなくなってしまう可能性もあります。そうなってくるとリファクタリングだけに時間を取られて,本来したかった変更にいつまでも着手できないということにもなりかねません。リファクタリングに着手する際は,よく検討してから行うようにしましょう。


スタイルが統一されているコードは読みやすいし,書くときも迷わなくて済むから,気持ち良く開発できるんだ。開発や修正といった本来の目的に集中できるようになるから,ミスも減るし,いいことずくめだね

基準がわかりやすいから,僕でも手始めに実践しやすそうですね。さっそく,自分のコードでやってみようと思います!

著者プロフィール

沖元謙治(おきもとけんじ)

株式会社クリアコード所属。プロジェクトで利用しているライブラリにバグを見つけたら,アップストリームにパッチを投げることを意識しています。

コメント

コメントの記入