この記事を書いた背景
業務でプログラミングしていると、もともとのソースコードが読みづらいために仕様を把握しきれず不具合を埋め込んでしまったり、逆に読みやすかったおかげで開発中に不具合に気づけたり、ソースコードの読みやすさに関連するさまざまな事象に遭遇します。
そのたびに「自分も読みやすいソースコードかかなきゃな」と思うのですが、いざほかの人にその感覚を説明しようとすると難しかったりします。
そんなときに「ここにまとめてあるから読んでみて！」と紹介できるドキュメントがあるとうれしいなと思ったので、私が考える読みやすいソースコードのうれしいポイントを書いていこうと思いました。
この記事の要約
- 読みやすいソースコードは内容を知らない人が修正するときに威力を発揮する
- 問題が発生して早急に調査・修正が必要なときに読みやすさに直面することになる
- だから読みやすいソースコードを書く技術に価値がある
対象の読者
- プログラミングをしながら書き方に迷うことが多い方
- 読みやすいソースコードがうれしいことがなんとなくわかる方
- 他のひとに読みやすいソースコードの説明をしたいけどなかなか苦戦している方
読みやすいソースコードと読みづらいソースコードの違いを体感しよう
さて、昔からプログラムの題材として出てくる FizzBuzz問題というものがあります。
これは基本的には1から順番に数字をカウントしていき、以下のルールに沿って画面に表示していくものです。
- 3の倍数の数字だったら Fizz を表示
- 5の倍数の数字だったら Buzz を表示
- 3と5両方の倍数の数字だったら FizzBuzz を表示
- それ以外の場合は単に数字を表示する
繰り返しと条件分岐があるので、プログラムするのにちょうどいい題材なんですよね。
例えばPHPで素直に書くと
<?php
for ($i = 1; $i <= 50; $i++) {
if($i % 3 === 0) {
echo "Fizz\n";
} elseif ($i % 5 === 0) {
echo "Buzz\n";
} elseif($i % 3 === 0 && $i % 5 === 0) {
echo "FizzBuzz\n";
} else {
echo "$i\n";
}
}
のようになります。
これと同じ処理をするのであれば
<?php
$i=0; while($i++<50){echo (!($i%15)?'FizzBuzz':(!($i%5)?'Buzz':(!($i%3)?'Fizz':$i)))."\n";}
という書き方でも同じように動きますし、
<?php
function isFizz(int $number): bool {
return $number % 3 === 0;
}
function isBuzz(int $number): bool {
return $number % 5 === 0;
}
function isFizzBuzz(int $number): bool {
return isFizz($number) && isBuzz($number);
}
for ($number = 1; $number <= 50; $number++) {
if (isFizz($number)) {
echo "Fizz\n";
} elseif (isBuzz($number)) {
echo "Buzz\n";
} elseif (isFizzBuzz($number)) {
echo "FizzBuzz\n";
} else {
echo "$number\n";
}
}
のように書いても動きます。
書き方に自由があるっていいですよね。
せっかくですのでどの書き方が一番読みやすかったか少し見比べてみてください！
読みやすいと感じるポイントは人それぞれ
おそらくほとんどの方は、1番目か3番目のソースコードが読みやすいと感じたのではないでしょうか？
どちらのほうが読みやすいと感じたかは、人によって何を重視しているかによって分かれるのではないかと思います。
例えば「2番目はどんな処理をやってるのか解読するのが難しい」とか「判定の意味が読み取りやすいから3番目が読みやすかった」とか、「3番目はやりたい処理のわりに記述が多すぎるから、今回くらいの規模なら1番目の書き方で十分」というような観点によって評価が分かれるのかなと思います。
「このソースコード読みやすい！（読みづらい！）」と感じた時には一歩立ち止まって、どういうポイントからそう感じたのかを自分なりに言語化してみると、読みやすいソースコードがどういうものかをイメージしやすくなるのではないかと思います。
おわかりいただけただろうか・・・？
ところで先ほどのソースコード、FizzBuzzのルール通りに動かない不具合があるものがあることにお気づきでしたか？
実際に動かしてみた方はすぐに気づいたかもしれませんが、ソースを読んでるだけだと意外と気づきづらいですよね。
さて、これが例えばプログラミングコンテストだとしましょう。
タイムリミットまであと3分のところでこの不具合に気づいてしまいました。
どのソースコードだったらタイムリミットまでに修正できそうでしょうか？
複雑なシステムの中で読みづらい書き方だったら
今回のFizzBuzz問題くらいの内容であれば「どれでも別に問題ないね！」という方もいるのではないかと思います。
しかしこれが業務で触っている1ファイル5,000行のファイルの中だったり、1秒停止すると数百万円の売上が失われるようなサービスの中にあったらどうでしょう？
そのような場合、問題の箇所がわかったとしても
- 他に同じような問題が残っていないか
- 修正することで他の場所に不具合を埋め込むことにならないか
- 修正をリリースするときに気を付けることはないか
など、他にもじっくり調べてからでないと危なくて修正をリリースをする判断ができない状況になることがよくあります。
また「FizzBuzz問題で、1からではなく0から開始にして、0の場合は0と表示してほしい」というような仕様変更があるかもしれません。
不具合が発生して調査をするときや仕様変更により当初想定していない処理を追加するとき、どのようなソースコードだったらうれしいかを考えてみると、読みやすいソースコードがどのくらい貴重なものなのか想像しやすいのかなと思います。
終わりに
私がプログラミングを勉強していたころはあまり読みやすいソースコードの価値にピンときていませんでしたが、仕事でプログラムを書くようになって、主に仕様変更や不具合などの原因調査の時にその価値を感じるようになりました。
これからしばらくは どうやったら読みやすいソースコードになるのか にフォーカスしていくつか記事を書いてみようと思います。
興味がある方はもう少々お待ちいただければと思います。
ちなみに先の例では、1番目と3番目のソースコードに不具合があります。
どうやったら直るのかは実際に修正してみていただくと、ちょっとお楽しみいただけるのかなと思います。
Discussion