生き様131. コードの読み方読ませ方
今回のまとめ
- 「コードは1行ずつではなく、処理の塊で読む
- 「処理の塊を意識すると、読みやすいコードになる
と、いきなり結論から今回は出しました。
月１の技術（っぽい）コラムです。
今回は、他人のコードを読むコツ、読みやすいコードを書くコツ的なものをお話します。
クセの強いコードたちとの出会い
僕が社会にでてプログラミングを始めた頃は、2000年代前半です。
僕の周りでは、手続き型言語とオブジェクト指向言語の過渡期ぐらいでした。
汎用機のクセが残るコードも多かった、と記憶しています。
僕が初めて担当した仕事は、既存システムのバグ修正と機能追加でした。
なので、必然的に他人のコードを読むことになります。
その後、新規開発の案件も幾つか経験しました。
ですが、本当に最初からというのは、片手程しかありません。
大体、既に先行して作業している人に合流する形態でした。
参考になるソースがあるので、それを参考に開発していました。
今のように、気軽にインターネットでコードを探せる環境はありませんでしたから。
つまり、20年超のエンジニア人生の中で他人のコードを読む機会が多かったのです。
コーディング規約が整っていない現場も多かったです。
つまり、多くのクセの強いコードを読み解かざるを得なかった、ということです。
そうした経緯で僕の「コードを読む技術」は培われたわけです。
処理の塊で読む
クセの強いコードを読む時、1行ずつ読んでいると、時間と気力を大きく消耗します。
18歳頃の体力と気力に満ち溢れていた頃ならいざしらず、40を超えるとしんどいです。
なので、大まかにしたいことの当たりをつけて、処理の塊としてコードを理解していきます。
そうすることで、全体を把握して、気になる所をより深く読む気力が残ります。
全体を把握するということは、全体の中の個々の役割を見るということです。
必要であれば、1行ずつ読むこともします。
コードは1行・1処理の集合体です。
その1行・1処理に意識を向けることは、とても大切なことです。
ただ、それ以上に、全体の動き、何をする為にこの処理があるのか。
「機能」というものに目を向けながら、コードを読むのです。
そういうポイントを忘れて、コードをただ眺めても得るものは少ないでしょう。
読みやすいコードの書き方
人によって、読みやすい・読みにくいの基準が違います。
最近、コードレビューを行っていて、その差に驚きました。
括弧の付け方１つでも、終わらない論争ができてしまいます。
ただ、それでも、誰にでも読みやすい最低限の形があります。
それに必要なのは「処理の塊を意識してコードを書く」ということです。
具体的には、以下のものになります。
- わかりやすい名前をつける
- コメントを書く
- インデントや行間を空ける
- 副処理（サブルーチン・関数・メソッド等）へ分割する 等
僕が主に開発しているC#には「#region～#endregionディレクティブ」という機能があります。
これによって処理をまとめるのに、大変お世話になっています。
この辺りで実例を使って示したいところですが、準備時間が足りませんでした。 汚いコードを書くのは、結構難しかったです。
代わりの読みにくいコードの実例として、極端な例ではありますが7行オセロを挙げます。
リンク先にある、7行で書かれたオセロのコードはとても読み辛いです。
当然ですね。人間が読むことを想定したコードでありません。
しかし、それでもしっかりとオセロが動作するそうです。
そして、このページの後半にあるコードを見てみましょう。
整形され、コメントが付加されており、読みやすいものとなっています。
この様に、ちょっと整えるだけでとても読みやすいコードになる、という実例でした。
文章とコードの類似性
以前から、コードを書くことと文章を書くことには類似性があると感じていました。
どちらも、手癖で漫然と書くことはできます。
しかし、それでは読み辛いものが出来上がります。
例えば文章を読みやすくする為、行間を空けたり、文脈や文章の流れを意識します。
1行に情報を詰め込みすぎない、というポイントもあります。
これはコードも同じです。
行間を空けたり、処理の流れに気をつけることで読みやすくできます。
1行に処理を詰め込むと読みづらくなる点も、文章と同じです。
実例を用意して提示することまでできなかったのが残念です。 これに関しては、改めてリベンジしたいと考えています。
文章を読むときに「単語ごとに読む」人を見たことがありますか？
居ないとは言いませんが、極マレな、専門のお仕事が趣味の人でしょう。
同じ様に、コードも、処理を細かく読む必要があるケースはマレです。
「処理の流れを掴んで読む/書く」ということが重要なのです。
以上！