まったく同じ処理フローでも、コメント、段落、空白行の使い方など、人によって「いろいろな見た目」になるのがプログラミングの面白いところですよね。しかし逆に言えば、「どんなに読みにくいコードでも同じアプリができあがる」ということでもあります。
では、アプリが仕様どおり動けば良いのか？と言ったら、もちろんダメですよね。趣味でも仕事でも、せっかく自分で組んだプログラムですから、とりあえず自分くらいは何年後でも楽にメンテナンスできるような準備をしておきたいものです。他の人に引き継ぐ場合にも、読みやすいコードが歓迎されるのは言うまでもありません。
そこで今回は、現役のプログラマーが「ソースコードを整えて読みやすくする」ために実践している「自分ルール」をいくつかご紹介します。
（この記事の紹介者：オブさん／アプリ開発者）
(便宜上、説明にはC#やJavaなどのオブジェクト指向言語の文法を使用しますが、アイデアとしてとらえていただければ、言語の種類にかかわらず適用できる内容です。)
ぽんぽこ
この記事の内容は？
設定したルールには例外を作らない
せっかく作成したルールでも、中途半端に守る程度ではあまり意味がありません。「急がばまわれ」とは本当によく言ったもので、ルールを1つ守るための数秒の手間が古いコードの保守を容易にし、長い目で見たときの総作業時間を確実に短縮してくれるのです。
ただし、いつまでたっても慣れることなく常に負担に感じるようであれば、該当のルール自体を見なおす必要があります。「有益、かつ、守れるもの」を「頭の中のルールブック」に少しずつ追加していくのがコツです。
メソッドや変数などの並び順を統一する
近年のプログラミング言語では、クラスの中の要素をかなり自由に配置できるようになっていますが、ここでは「配置の順番を統一する」というルールを追加してみます。
どのような順番かは個々人にゆだねるとして、「すべてのクラスで常に統一」することにより、特定の要素を探す時間を短縮できます。
考え方としては、二分探索アルゴリズムのようなものです。
- Public変数群
- Private変数群
- Publicメソッド群
- Privateメソッド群
- プロパティ群
- etc…
たとえば、上記のようにソートされていて、Publicメソッドのひとつが修正対象だとわかっているとします。その場合、自分が最初に視点を落とした場所がPrivateメソッドなら、対象となる箇所はそれより少しだけ上の行にあるということになりますよね。
慣れてきたら「デリゲート関連は各グループ内で上位に」など、順番付けのルールを細かくしていくことにより、目視での検索がさらに楽になっていきます。
ただし、要素をソートしていればクラスをどれだけ肥大させても良いということではありません。適切なサイズで設計したうえで、さらに読みやすくする工夫をするというのが原則です。
コメントブロックの飾り文字に意味を持たせる
メソッドや変数ブロックのヘッダコメントを置く際、飾り用の文字で囲う方も多いと思いますが、その「飾り文字自体に意味をもたせる」という使い方をご紹介します。
//+++++++++++++++++++++++++++++
// 支払い機能
//+++++++++++++++++++++++++++++
たとえば、「 + 」なら Public、「 – 」ならPrivate、他にも、これら以外のスコープ、プロパティ、処理系特有のイベントなど、自分で見分けやすい文字を決めておけば、ソースコードをひと目見ただけで、クラスにどんなメンバ要素が含まれているのかを把握できるようになります。
エディタの色設定だけでは対応しきれないものも識別できますし、前述の「メンバ要素のソート」と合わせてクラス内の見通しを良くしておくことにより、古いソースコードでも「目的の場所を見つける」ことがとても楽になります。
ドキュメントの自動生成機能を使用している方などはちょっと適用しにくいかもしれませんが、個人的にかなり気に入っているルールです。
ソースコードの自動整形機能を利用する
インデント、キーワード前後の空白、括弧の付け方など、同じパターンの処理は常に同じ書き方に統一するべきです。ルールとして徹底することで「見慣れた形」が増えていき、ぱっと見で処理の流れを判別しやすくなります。
そこで利用できるのが、ソースコードの書式を自動で整形するための機能です。多くの一般的な統合開発環境で用意されており、かなり細かいところまで設定できます。
いちいち自分で調整しなくてもすべて自動で整えてくれるわけですから、数々の便利機能の中でも特に積極的に使用すべきもののひとつです。
空白行の入れ方を統一し、時には意味をもたせる
空白行は何行入れても文法上の意味は同じですが、前述したような「見慣れた形」としてのコード認識率にも影響するため、気分次第で変化させるのはあまり生産的とは言えません。
まずは、「見やすさを保ったまま、なるべくスクロールせずに編集できる」パターンを自分なりに決め、全ての箇所で使い方を統一します。
基本のパターンが徹底されていれば、たとえば「? 行以上あいていたら～」など、例外のパターンに意味をもたせることができるようになります。
具体的には、「あえて1日おいて頭をリフレッシュさせてから見直す予定の処理ブロックの前は3～4行程度あけておく」というように、改行キーを数回たたくだけで「明日作業する自分に簡易メッセージを残す」ことができるわけです。
(上記の例は、個人的なルールとして実際に使用しているものです。もちろん、具体的な作業内容を書いておくべき場合にはToDoコメントに置き換えます)
修正コメントでコードを汚さない
ソースコードのバージョン管理システムが存在しなかった時代には、コード内に「日付、修正者、何を、どのように」のようなコメントを残すことが一般的でした。修正ごとにネストされていくコメントブロックが、生きているコードより多いものもよく見かけたものです。
幸いなことに、今では優れた管理システムが容易に手に入りますから、修正コメントでソースコードを汚していく必要はありません。常にすっきりと見渡せる状態を維持し、修正履歴の管理はすべてまかせてしまえばよいのです。
もちろん、管理システム側に修正部分を登録する際には、作業案件ごとに適切なコメントを設定することが必要です。「月日修正分」など、何を修正したのかまったくわからないコメントは、バージョン管理の利点を活かすどころか、該当箇所を探す手間を増やすことになってしまいますので絶対にやめましょう。
ちなみに、バージョン管理システムの導入は、コーディング作業全体の精度を上げるための必須条件と言っても過言ではありません。まだ利用したことのない方は、評価用のプロジェクトなどで試してみることをおすすめします。
ぽんぽこ
まとめ
いかがだったでしょうか？
今回は、「ソースコードを整えて読みやすくする」ということに焦点をあて、汎用のアイデアとして利用できそうな例をいくつかとりあげてみました。
コメントの書き方や命名規則などは既に多くの方がルールを持っていると思いますし、他にも可読性、保守性を上げていくための要素はたくさんありますよね。
経験上、「ちゃんと守れる」ものである限り、ルールが多いほどメンテナンスを含めたコーディング作業は楽になっていきます。誰に強制されるわけでもなく、自分がやりやすい方法を探っていくだけのことですから、試行錯誤も結構楽しいものです。
この記事をたまたま目にした皆さんも、未来の自分のためにちょっとずつコードの整理整頓を始めてみませんか？
以上、「現役プログラマーが実践する、読みやすさのための自分ルール」のご紹介でした。
ぽんぽこ
