以前から何年も言い続けていますが、私はプログラム書くのは好きではないのです。逆に、好き好みで特定の書き方に固執するっていう発想もなければ「めんどくさいので文字数減らすか」みたいな考えもあんまりしないので、ハカーの皆様と比べると若干のアドバンテージがある部分もあるやもしれず。
Javaとか書いてる時に
StringBuilder b = new StringBuilder();
とか見るとホント吐き気がしまして、最低でも
final StringBuilder builder = new StringBuilder();
とかくらいは書いてほしいなーと思うことしきり。
＃バッファサイズを指定できたかは知らんですが、それは可読性というよりは効率の良いコード生成という意味が強いので絶賛スルーすることが多いです
んまぁ自分が書いてるコードの走る対象がマジですんごくたくさんあったりするので、そういったたぐいのtweakはボトルネックにならないしむしろそういう効率重視のコードを書くと、後から読んだときに「なんでここでわざわざcapacity指定してるのかしらー？」とか考えちゃって色々苦労するので、ベンチマークでよほどそれに意味があると分からなければ、バッファサイズとかは指定しないことにしてます。
バッファサイズを指定するとか、ただ正規表現を使うのではなくオートマトンを手で書いてたりする場面ではそれがなんで必要もしくは有用なのか、コメントをかなり多めに書いておくのが私の習慣になってます。昨日書いたコードでは、特定のコードパスだけピンポイントに検出してRuntimeExceptionを投げるという処理を書きまして、大体こんな感じのコメントにしたのでした
(本当は英語)
仕様が公式にhogehogeによってfinalizeされていないため、現時点 (2010-07-12) では念のためこのコードではフラグXXXを指定してデータを生成することを禁止している。ただしフラグXXXが指定された状態での読み込みは受け入れる。これは他のソフトが仕様策定前のバージョンを指定してデータをを生成する可能性を考慮してそれを可能な限り読み込めるようにしつつ、こちら側では他のソフトに迷惑をかけないようにするためである。
この一時的な状況のためだけにドメイン固有のExceptionクラスを作ると、API上それが永遠に残ることになるため、ここではRuntimeExceptionを投げることでAPIに影響を与えないようにしている。
書いてて思いましたが、それならRuntimeExceptionを継承してTemporaryRestrictedExceptionとか作った方が意味が分かりやすいかなー……。さすがにこの1ケースのためだけにそこまでやるのはどうだろうと思うのでやらないですが、2箇所以上そういうのがでたら考えますね
上のコメントに対する実際のコードは超瑣末なif文と"throw new RuntimeException("Not supported");" みたいなすんげー単純なもんだけだったりしまして、コメントが実コードの3倍くらいあったりするです。
「可読性」とか重視するのであればコードの意図をコメントに残すのはやっぱりやっといた方がよいなー、と思うことしきりですね。何をやってるのかを書くのはむしろ逆にあんまりお勧めできないんですが、「なんでそのコードがそうなってるの」ってのを書いておくと1年後に自分がそこを読み返すときに「なんでだっけ」と1分悩むってところが30秒で収まりまして、それが100回繰り返すと3000秒節約出来るんです。それに、何より後でそれを読むかもしれない人々がやらかしかねない勘違いとバグ埋め込みを減らせます (これが一番重要)
難しいのは、あんまり冗長にコメント書くと後でそこのコードを直すときに前後のコメント大体全部見なおさなくちゃいけないところでしょうか。だからこそ「なぜそう書くか」は書いても「何をしているのか」は書かない方がよいのです。本当に二度手間なので。「なぜ」はそこのコードを修正する際にコード修正とは別に変わる (意図がその結果とは独立に変化する) ことが多いので、二度手間にはならないのです。「面倒」と思う人が多いわけですが、最初に書いたとおりプログラムが好きでもない私に取っては面倒かどうかはこの際どうでもよろしい
そーいうのが私の考える読みやすさでありますが、その前にこのブログの可読性を上げろというバッシングが来そうですね分かります
