リーダブルコードを読んでみて気になったこと

オライリー(O'Reilly)から出版されたリーダブルコードについてです。 ほとんどいいがかりみたいですが、読んで気になったところをメモしておきます。

これから文句みたいなことを書きますが、この本はいろいろな発見があって、Web専業といった特定の業務に特化していて、いろいろなシステムに触れる機会が少ないような方には特にお勧めです。

最近Androidアプリを作ってJavaばかり触っているので、特にこの観点から気になった点をまとめました。

• 「関数の戻り値にretvalを使うな」について
• Syntactic Sugarであるswitch文を排していない
• まとめ
• おまけ：自分が書くコードはリーダブルか (小学生読書感想文調)

「関数の戻り値にretvalを使うな」について

型のないいわゆるLLと呼ばれるようなスクリプト系言語を扱う場合には、tmp/retvalのような名称は使うべきではないと強く思います。

しかし型のある言語の場合には、メソッドの先頭で戻り値のオブジェクトを格納する変数を用意しておき、最後にreturn ret;とするのは悪い習慣だとは思いません。

問題なのはメソッドの戻り値になるオブジェクトを格納する変数を、メソッドの途中に宣言をする事です。 読み手にゴールを提示せずに書き始め、そのゴールを途中にそっと忍び込ませるような真似は、決してするべきではないと思います。

C言語のように全ての変数をメソッド/スコープの先頭で宣言するべきとは思いませんが、処理の全体に関連する変数、定数の宣言はメソッドの先頭で行ない、それが処理全体の主人公であるという見通しを読者に伝えるべきです。

  public String findUniqueNameFromIndex(int index) {
     String ret = "";
     ...
     return ret;
  }

すべてのメソッド定義でこのような形式に沿った記述をしていれば、その処理がやや冗長になっても途中でターゲットを見失わずに済みます。

処理の途中で使用する変数は、そのスコープにもっとも近い場所で宣言をすることで、読者にそのスコープに関連する事を強く印象づける事ができると考えています。

大切な事は、全ての記述を特定の形式に収める事で、読者の興味、関心を他に移さずにコードに集中させる事です。

Syntactic Sugarであるswitch文を排していない

読んだ限りではswitch文について言及している部分はありませんでした。 まぁこれは趣味な部分も含んでいるので、こうでなきゃいけないというコンセンサスは得られないと思います。

ただ、switch文は単一スコープの中に記述する形式になっているので、一度あるcase文の中で宣言した変数は、他の個所で使う事はできません。break文を忘れて、意図せず変数に代入が行なわれて気がつかずに特定の処理でバグが入るといった可能性があります。

一般にswitch文はif-else文で置き換えが可能で、スコープが明確に分かれているif-else文を使うのが個人的にはお勧めです。少なくともbreak文を抜かすような真似はif-else文ではできません。

まぁswitch文は便利ですし、組み込み系のプログラミングで8bitの入力を処理するのに255個のcase文があるコードを見た事もあるので、環境によって流儀はあると思いますが、あえてswitch文は止めようといっておきます。

まとめ

リーダブルコードは読者を意識したコーディングを行なうための、とても良いガイドになっていると思います。

昔から特定の言語を対象にした、「べき・べからず本」というのはありましたが、どうもTipsが命令的で柔軟性にやや欠けるような印象がありました。

リーダブルコードのテーマは昔から出版されている本と比較して、とても斬新というわけではありません。

しかし、押し付けようとせずに、プロ・アマ問わずに誰でも読める記述になっている事はお勧めのポイントとして、とてもとても高く評価しています。

この本は誰が読んでも参考になりますが、できれば10代で、この本を読んで、最初から読み手を意識したコーディングをする方が増える事を願っています。

最後に、深夜に書き始めたせいか、いつもどおり、そしていつもにも増して上から目線になってしまいました。 ごめんなさい。

おまけ：自分が書くコードはリーダブルか (小学生読書感想文調)

私は、ずっとこういう事をテーマにしているはずなのに、いまだに最初からリファクタリングが不要なコードを書く事ができていません。

これは小説家が何枚も原稿用紙を破るように、当たり前の事なんだと思ってきました。 でも、リーダブルコードを読んで、プロの人達はこんな事はしなくても経験を積めばリーダブルで高可用性なコードが最初から書けて、こんな素晴しい本まで書けるようになるんだと知りました。

私は以前に同じようなコードを書いた事がなければ、いろいろ設計らしき事をしてから作り始めても、一つのメソッドが100行くらいになってしまう事は、たまに起ります。

1つのスコープでそんなに長いコードを書いているので、tmpという変数名を使ってしまうと、後でtmp2のような変数名を使わなくてはいけなくなるので、結果として説明的な変数を使うようになります。

それから、処理の内容をできるだけ分割して、意味のある単位で外部のメソッドとして括り出して、その処理に責任を負うのに相応しいクラスに処理を移します。

そんな作業を何回も繰り返して、やっとそれなりに適当な粒度のメソッドに分割されたコードを作る事ができた、と思う事ができるようになります。

そして、いくつかの責務を負っているクラスを分割したくなります。 この衝動はどうしても抑える事ができないのですが、よくよく考えずにやってしまって、最終的にgit checkout -fをしなければいけなくなる時があります。

きっとプログラミングが仕事の人達は、最初から見通しをつけて空のメソッドをどんどん書いて、後から、その中に処理を書いていく事ができるんだと思います。何年も仕事をしていて、いまだにこんな事をしているのは自分だけに違いないと思うと情けないけれど、負けずに頑張っていきたいと思います。

この記事で取り上げた品々