yumeの日記: 『リーダブル・コード』読んだ。 4
apple booksで読んだ。でかいiPadなのでコードも読めたが、書籍だったらコードの部分ももっと読みやすかったのかな?
だいたい要約すると:
・適切な名前をつけよう
・適切なコメントをつけよう
・変数を減らして、スコープを縮めよう
・ライブラリ を使おう
改めて列挙すると、かなり普通のことを言ってるな。
細かいテクニックとしては、ガード節、関数の抽出、説明変数、処理の種類ごとにブロックにまとめるなどなど。
特に最後のあたりの「時間カウンタを設計する」の章がおもしろかった。
webサーバの直近1分と1時間の転送バイト数を把握するという仕組みを、実際にコードを書きながら読みやすくしていくという章だが、まず最初にできる試案1はなんとなく自分でもざっくり想像したようなものだった。
これにはパフォーマンスに問題があるので、コンベアーキューと時間バケツいう概念を作り、拡張性とパフォーマンスにすぐれていて、しかもかなり読みやすいものがメキメキできていく。なんというか、トタンを組み合わせてなんとか屋根っぽいものを作れるなぁ、とか思ったら横からマッチョがすごい勢いで丸太小屋を作っていく感じがした。
あとその前の章は「テスト」に関するものだった。テストを前提に関数を書くと結果的によいコードになっていく……らしい。なんだそれすごい。
だが、テストとやらをやったことがないのでほとんど飲み込めなかった。テストという概念は「ある関数を、いろんな引数で実行する関数的なやつ」ぐらいのイメージである。便利そうだなとも思うが実際どうやって使うんだろう? テスト用のクラスを作っておいて、そいつが特定のクラスの関数をぶんまわしまくるみたいな? なんだか手間が多そうというか、そういうの簡単にやるうまいやり方があるんだろうな。Unityにもテスト関係の何かがあったとぼんやり覚えているので、今度調べてみよう。
テスト (スコア:0)
だいたいそんなイメージで合ってます。
例えば、ここでいろいろコメントされてソースを修正したりしていると思いますが、
テストがきちんと書けてるなら修正前後で同じ動作しているということがだいたい保証されます。
コードを修正していくということを前提に考えると、
時間カウンタの設計でもいきなりコンベアーキューと時間バケツを利用するなんてはりきらずに、
とりあえず思いついた試案1で実装してみるなんてことができるわけです。
あと、テストというのは基本的に一つの機能に一つ以上書くことになります。
そうするとテストが適切にできるプログラムを書こうとすると自然と機能が分割されることになり、
以前話題に上がった一つのクラスに何でもかんでも機能を組み込んだり複雑に絡み合っていて
クラスや関数を分割できないなんてことも少なくなります。
昔のこれが普通になったらいいなが乗ってる本 (スコア:0)
いかんせん古い本である。
そして古いことは今では通用しないものである。
例えば変数は使う直前に作成すると書かれているがリーダブルコードから見た昔には変数は関数の頭で一通り用意するのが普通だった。
これに関していえば関数はミニマムが変わらない価値観なのでこっちに従えば関数の頭で必要な変数を一通り用意しても困らないはずナンダけどね…
Re: (スコア:0)
>例えば変数は使う直前に作成すると書かれているがリーダブルコードから見た昔には変数は関数の頭で一通り用意するのが普通だった。
いやそのくらい言語仕様を見て、適宜自分で補正しろよ……
そこまで説明しなきゃわからんバカだと、もはやプログラムを書かせられない。
むかしあったのは、
「デストラクタに書くような奴は、javaだとどうすればいいんですか?」
だったわ。
彼等には「なぜそこに書くのか」が理解出来てなくて、
今までそうしていたから惰性でそうしていただけだった。
Re: (スコア:0)
私が書いたことをくどくど解説してくれてありがとう?