きれいなコードを書くための鉄則

先日に続き、良いコードを書くための本を読みました。読書な休日も素敵なものです。秋ですからね。今日読んだのは"きれいなコードを書くための鉄則"です。

本のタイトルの通り、きれいなコードを書くための鉄則が、易しめに書かれてあります。
目次はこんな感じです。

鉄則その１ メソッド(関数)は○○行以下に!?
鉄則その２ 命名規則の考え方
鉄則その３ わかりやすいコードを書く
鉄則その４ 見た目の美しく
鉄則その５ 再帰呼び出しの使いどころ
鉄則その６ 探索アルゴリズムの選び方
鉄則その７ 整数型の使い方
鉄則その８ フラグとビットフィールドは必要最小限に
鉄則その９ 文字と文字列の落とし穴
鉄則その１０ 日付と時刻の持たせ方
鉄則その１１ 言語を選ぶ
鉄則その１２ デザインパターンをどう使うか
鉄則その１３ メソッドやクラスの変更と廃止
鉄則その１４ 小規模なシステムと大規模なシステムの違いを考える
鉄則その１５ リファクタリング
鉄則その１６ きれいなコードを書くための最後の鉄則

また、良いと思った部分を引用していきます。

コードは人と人とのコミュニケーションの手段でもあるのです。

コードは、コンパイラーやインタープリターが解釈するためにあり、そこには「美しい」なんていう概念はありません。しかし、コードはコンパイラーやインタープリター意外にも、他人や、将来の自分が読むものでもあります。そのため、コードは人と人とのコミュニケーションの手段と例えられているわけですね。

boolean型の値はtrue/falseを比較しない

if文の判定式はbooleanである必要がある、Javaのお話です。「if (validFlag = true)」と、等価演算子を代入演算子にしてしまうミスを防ぐために、普段から、「if (true == validFlag)」と、左オペランドに定数を置くような習慣を付けるような、コーディング規約がたまにあります。しかし、この記述は不自然なので、規約には「boolean型の値はtrue/falseを比較しない」というルールにしとけばいいじゃん、ということですね。

if (validFlag == true)

ではなく、

if (isValid)

とすべきということです。

木構造のデータを処理するとき

再帰呼び出しを使ったコードを書いたことがないのですが、使う唯一の機会は、木構造のデータを処理するときだと書かれています。そういえば、そう考えると、使う機会はあったかもしれません。

このフラグって、どうしても必要なの？

「あるメソッド内だけ」といったように局所的にしか使われないようなフラグは、ほかの(もっとすっきりとした)解決方法があることが多いものです。

と書かれています。確かにその通りな気がします。気を付けようと思います。

同じメッセージは６回以上出力せず、６回目を出力しようとしたとき「(messages suppressed.)」と表示する。」

アプリケーションには基本的にロギング機能を実装するのですが、これは良いと思いました。というか、Linuxのsyslogとかで、よく見るテクニックなのですが。。TCPクライアントサーバーシステム等で、マシンにIPアドレスを適切に設定していなくて、bindエラーがリトライで延々に出続けていたり等、よくある話です。早速今度使ってみようと思います。

近道のように見えても、案外そうではない

我が社でも「３ヶ月しか稼働しないアプリだから、やっつけで作って」みたいな指示でコーディングすることがあるのですが、そのコードが別のシステムで使い回されたりして、結局そこで「やっつけ」で組んだコードが長年使い回されてしまったり等、わりとある話です。自然と流れるようにスマートに、綺麗なコードを生み出せるプログラマーになりたいですね。

ということで、今日も良書に巡り会えました。ではでは。