個人的に綺麗なコードを書くために心がけているもの。 数が多いので、効果があると個人的に思っているものだけ集めてる。
なぜ読みやすく書くのか
読みやすいことに興味がない人のコードで、本当に汚ければ遠慮なく指摘するし、そのコードを保守したいとも触りたいとも、仕事でなければ関わりたくすら無い。
一度だけ書いて、二度と保守もメンテも必要無い書捨てのスクリプトなら、とやかくは言わない。
しかし、多くのプロダクトがそうであるように、アプリケーションはメンテナンスする。
それはバグ改修だったり、性能向上だったり、機能追加だったりする。
その時、作りを理解するのは何か?
Excel 方眼紙に書いた、行単位では意味が読み取れないような日本語の文章か?
違うだろ?
結局のところ読んで、理解して、手を入れるのは コード なんだ。
加えて実際の修正量とコードを読む量どっち多い?
聞くまでもない。
間違いなく読む量だ
なら、読みやすいコードこそ把握しやすく、バグも埋め込みにくく、容易に修正できるものだと言えるのでは?
だから 綺麗に書かれたコードが正義なんだ と考える。
他にも、コードは仕様上でも重要なドキュメントだ。
- コードは設計だ
Jack W. Reeves 氏の論文。 - なぜコードが重要なドキュメントなのかというと、 詳細かつ正確なドキュメントはコードしかないからだ
Martin Fowler 氏の論文。
読みづらいドキュメントを誰が訂正するんだ?誰も触りたくなんて無い。
だから学ぶんだ。
美しく書くには
コードの美醜と言うものを知らなければできない…と経験で上がってきた人は居ると思う。
それも方法の一部であることは事実である。
美しいとは経験だ。当然ながら無垢な3歳時が名画を見て「すごい」とは思っても「美しい」とは思わない。
それは経験のなせることだからだ。
そうした意味では OSS のソース、それも多くのマージがあったものが良いかもしれない。
(複数人がメンテする必要があるということは、それ相応に読めるように出来ているだろうと予測はできる)
だが、もう一つ学ぶ方法がある。
それは「 原則を学ぶ 」だ。
原則自体は、書籍「プリンシプル オブ プログラミング」を見ていただくとして、特に効果のあった思考を順におっていこうと思う。
本にもなっている。気になる人はこのエントリの下の方参照。
普段気にしてるもの一覧
- 基本方針
- 設計レベルで気をつけろ!
プロジェクトが燃える原因は大体上流だ。プログラムがこんがらがるのは大体設計だ。- 車輪の再発明は避ける
- YAGNI原則(Wikipedia)
You aren't gonna need it. そんなのまだ必要ないよ(だからその分シンプルにしろ)。 - 設計はトップダウンとボトムアップ
- GRASPパターン(Wikipedia)
General Responsibility Assignment Software Pattern.
オブジェクト指向設計の基本とは、適切なクラスに適切な責任を割り当てることである - http://d.hatena.ne.jp/asakichy/20090331/1238472501
設計の簡素化のため、オブジェクトの利用、オブジェクトの生成・管理を混ぜて考えてはならない。 - オブジェクトの状態は作らない
- 1 クラス 1 機能、1 メソッド 1 処理の徹底
- コーディングで気をつけろ!
- くたばれカーゴ・カルト・プログラミング
- ユーティリティクラスを書きまくる
- 全メソッドをテストする前提でユニットテスト出来ない設計はしない
- 1 クラス 1 機能、1 メソッド 1 処理の徹底
- ボーイスカウトの原則
- 名前の付け方に気をつけろ
- 段落とフォーマットを揃える
- 適切なコメント
- ユーティリティクラスを除いて、依存するクラス数は 10 個以下に抑えよう
- 分岐一つはバグ一つ埋め込むものだ
- 条件式の作法
- 変数は極力使うな
- null は滅びればいい
- ネストは二段、最悪でも三段
- 一つの処理の流れが 5 行を超えたら、メソッド化を考える
- メソッド行が 20 超えたら作りを疑え
- メソッド数が 10 を超えたら、クラス分離を考える
- 仕様を悪用するんじゃない
項目が多いので、別のエントリで色々書こうと思う。
参考
- ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
smalltalk は自然言語に近い公文がウリ。読ませるコードについての示唆は、他言語でも有効です。 - リーダブル・コード
往年の名著。初心者向けに色々書いてくれている。ただし、一部は陳腐化しているかもしれない。 - プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
なぜ僕が3年目の時までにこの本が出なかったのか…。実感してそうしようと思うには、実務経験1-2年くらい欲しい。 - 新装版 リファクタリング 既存のコードを安全に改善する
ボーイスカウト(ボーイスカウトたるもの「帰るときには、自分が来たときより綺麗にしなければならない」)の原則を守る方々に…。 - オブジェクト指向の法則集(オブラブ様)
オブジェクトラブとはいったものです。