こすげのブログ

金髪エンジニアのブログ

【読書】「Code Complete 第2版 上 完全なプログラミングを目指して」の感想 その6

はじめに

今回は第3部 変数第10章 変数の使用から第11章 変数名の力までを読みました。

だいたい2章分を2時間くらいかけて読みました。

変数に関してはしっかり勉強したわけではないのでとても勉強になりました。

特に変数のいい名前の決め方など...。

現在の読了率は63%となっております。

残り少しですね。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

ハイライト

今回は結構多いです。

そして多分当たり前のことかと思います。

だけど、変数の事についてしっかり書かれているものを初めて読んだのでご容赦ください。

第10章 変数の使用

「関連する作業を1つにまとめる」という近接の法則の一例である。

この法則は、コメントは説明するコードの近くに置くこと、ループの準備をするコードはループの近くに置くこと、複数ステートメントはストレートなコードにまとめること、などにも当てはまる。

10.3 | 変数の初期化のガイドライン

これは変数の初期化を使用する場のできる限り近い場所でやったほうがいいと云う話でした。

これはメソッド内での話です。


■クラスのメンバデータはコンストラクタで初期化する

ルーチンの変数をルーチン内部で初期化する必要があるように、クラスのデータはクラスのコンストラクタで初期化しなければならない。

コンストラクタで割り当てたメモリは、デストラクタで解放しなければならない。

10.3 | 変数の初期化のガイドライン

クラスのメンバ変数に関してです。

こういうのって昔は決まりなかったんだなーって思うと怖いですね。

JavaでもSwiftでも初期化されていない変数はコンパイルでエラーを出しますからね...。

ただObjective-Cは違いましたね...。

何度NSArrayのメンバ変数を初期化してなくて怒られたことか。


変数の「スコープ」とは、変数の知名度、つまりどれくらい有名かについて考えることを示す。

スコープは可視性とも呼ばれ、変数がプログラムのどの範囲まで知れ渡っていて、どの範囲で参照できるのかを意味する。

10.4 | スコープ

スコープについてでてきました。

これ、学ばないと知らないことですよね。

先日、外注さんソースコードを読むことがあったのですが、ほとんどグローバル変数で宣言されていたりとどこでどの変数が見られているのかわからない状況がありました。

まあ仕事の良し悪しは置いておいて、ソースコードを見られることを前提に考えたら恐ろしいなと。


隠ぺいできる情報が多ければ多いほど、一度に注意しなければならないことが少なくなる。

覚えておかなければならないことが少なければ少ないほど、覚えておかなければならない情報を1つ忘れてしまったためにミスを犯す可能性も少なくなる。

10.4.5 | スコープを最小限に抑えることについて

スコープを最小限にする(メソッド内のみに抑えるなど)をすることのメリットです。

そしてこれを意識すれば、だいぶきれいになるのではないかなと。


バインディングタイムとは、変数にその値が結び付けられるタイミングのことを言う(Thimbleby 1988)。

10.6 | バインディングタイム

変数がバインドされるタイミングのことを取り上げた項でした。

そして、いつどこで値が変わるかわからないから信用せずそれに対処するようにしようという話でした。


1つの変数を2つの場所で異なる作業に使いたいことがある。

だいたいは、変数にどちらかの用途にふさわしくない名前が付いているか、両方に「一時的な」変数(xやtempといった不親切な名前)が使われているか、どちらかである。

10.8 | 1つの目的に1つの変数

これ、とてもドキっとしました。

やったこともあるし、やっているソースコードを見たこともあって。

そしてそれを説明されて納得してそのまま使ったこともあるんですよねー。

第11章 変数名の力

変数に名前を付けるときに最も重要なことは、変数が表すものを完全かつ正確に説明するような名前を付けることである。

11.1.1 | 名前をつけるときに1番大切なことは

この完全かつ正確というのが難しくて...。

でも出来てる人はこれがしっかりできてるので、処理が間違わないんだろうなと思います。

シンプルにしようと短い単語使ったら説明不足になるし。


覚えやすい良い名前は、一般に、解決策ではなく問題を表現している。

良い名前は、方法(how)ではなくもの(what)を表すことが多い。

一般に、名前が問題ではなく計算の一部を表すとしたら、それはものではなく方法を表す。

11.1.2 | 問題指向の名前

これ、初めて知りました(恥ずかしながら...)


コードの一部を「推理」していることに気付いたら、変数の名前を変更することを検討しよう。

推理小説の殺人事件ならまだしも、コードは推理する必要などないはずである。

コードは読んで理解できるものにしよう。

11.2.2 | 状態変数の命名

このちょっと挟んでるやつが、多いんですよ...。

これは今後意識して取り組まなければならないものですね...。


ブール変数名の先頭にIsを付けるのが好きなプログラマもいる。

そうすると、変数名はisdone?、isError?、isFound?、isProcessingComplete?といった疑問文になる。

これらの質問にtrueまたはfalseで答えると、変数の値になる。

この方法の利点は、あいまいな名前ではうまくいかないことである。

isStatus?ではまったくわからない。

欠点は、単純な論理式が少し読みにくくなることである。

if ( isFound )if ( found )よりも少し読みにくい。

11.2.4 | ブール変数の命名

これはブール変数を状態を表す(読み込み中か、チュートリアルは終了したか...etc)のに使う時に考えることかと。

ちなみに僕はis~ってやる派です。

そういうソースコードを読んできたからです。

ただちょっと考え直す必要があるなと思いました。

■名前はコードの書き手ではなく読み手にとって重要なものである

たとえ自分が書いたコードでも、半年以上見ていないと、名前の意味を理解するのに手間取る部分が出てくる。

このような問題の原因となる省略法は改めよう。

11.6.3 | 省略形の注意事項

そうですよね。

感想

本当に学んでない部分を知れたなという章でした。

「変数とは〜」とか「名前のつけ方は〜」なんて一から教わるのものなんですかね?

僕はソースコードを読みながら体感した問いう感じでしたが。

大事なこと読めたなーって思いました。

読めば読むほど、大事な部分の経験値が足りてないなって思いました。

これも人と一緒にものを作ってきた経験がないからなのかなって本読んで思っております。

あ、人と一緒というのはペアプロ複数人のエンジニアとやるとかそういうことっす!

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

終わりに

ということでReSwiftの流れからJavascriptフレームワーク?って呼んでいいのかな?

React.jsとかRedux.jsとかに興味を持ち始めました。

facebook.github.io

redux.js.org

自己紹介ページ、だいぶ放置しちゃってるので使ってみようかな...。

誰か、これやったらいいよ!みたいなのあったら教えてください...。

以上になります。