「プログラミング作法 THE PRACTICE OF PROGRAMMING Brian W.Kernighan,Rob Pike 福崎 俊博 訳」の第1章を読んで
■メモしておきたいと思った箇所
第1章 スタイル
1.1 名前
名前は、情報を含み、簡潔で覚えやすく、できれば発音可能な名前にしなければならない。
スコープの広い変数ほど名前から伝わる情報量を増やす必要がある。
「グローバルにはわかりやすい名前を、ローカルには短い名前を。」
「統一しよう。」
関連性のあるものには関連性のある名前をつけて、関係を示すとともに違いを際立たせるようにすること。
「関数には能動的な名前を。」
関数名は能動的な同士を基本にし、とくに問題がなければそのあとに名詞をつけることにしよう。
「名前は的確に。」
誤解されやすい名前をつけると、摩訶不思議なバグを発生させる可能性がある。
1.2 式と文
式と文は出来るだけ人目で意味がわかるように書こう。作業を実行するコードはこの上なくきれいに書く。演算子の前後に空白を入れて関連性がわかるようにする。
「構造がわかるようにインデントしよう。」
「自然な形の式を使おう。」
式は自分で音読するつもりで書こう。
条件式に否定が含まれていると、間違いなくわかりづらくなる。
「かっこを使ってあいまいさを解消しよう。」
自分の意図を明確に表現できる。
「複雑な式は分割しよう。」
つい調子に乗って何でもかんでも１個の構文に詰め込んでしまいがち。
「明快に書こう。」
本来の目的はあくまでも明快なコードを書くことであって、小賢しいコードを書くことではないのだ。
「副作用に注意。」
++などの演算子の副作用に注意。
1.3 一貫性と慣用句
一貫性はより優れたプログラムをもたらす。
同じ作業が毎回必ず同じ方法で処理されるようになっていれば、何か違っている部分があったときに、それが注目に値する本当の違いだとわかるようになる。
「インデントとブレースのスタイルを統一しよう。」
１つのスタイルを選んでそれを一貫して利用すればいいだけで、議論するのは時間の無駄でしかない。
「慣用句によって一貫性を確保しよう。」
自然言語と同じようにプログラミング言語にも慣用句がある。
どんな言語でも、その言語の慣用句に馴染むことが学習の中心。ループの記述、インデントなど。
「多分岐の判定にはelse-ifを使おう。」
if文がネストされて並んでいるのは、完全な間違いとは言えないまでも、具合の悪いプログラムの兆候を示していることが多い。
else-ifを使い、明快なコードへ。
1.4 関数マクロ
「関数マクロはなるべく使うな。」
「マクロの本体と引数はカッコに入れよう。」
マクロの原理はあくまでもテキスト置換。
1.5 マジックナンバー
「マジックナンバーには名前をつけよう」
0と1以外のすべての数値はたいていマジックナンバーであり、それ独自の名前をつける必要がある。
プログラムのソースに生の数字が出てきても、その意味や根拠はさっぱりわからないし、プログラムを理解したり修正したりするのが難しくなる。
「数値はマクロではなく定数として定義しよう。」
「整数ではなく文字定数を使おう。」
0という数値はプログラムの中のさまざまな文脈に登場することが多い。
同じ0でも、役割はそれぞれ違う。（NULL or 0 or 0.0 など）
「オブジェクトサイズは言語に計算させよう。」
1.6 コメント
コメントの目的はプログラムの読み手を助けることにある。
コードを見れば一目でわかることを書いても仕方ないし、コードと矛盾していたり、見た目に凝って読み手の注意をそらすようなコメントも役に立たない。
注目すべき細かい点に簡潔に触れたり、もっと大きな視野で処理を解説することでプログラムの理解を助長するようなコメントがベストだ。
「当たり前のことはいちいち書くな。」
以下、悪い例。
i++; // iをインクリメント
default: break; // デフォルト
return SUCCESS; // SUCCESSを返す
「関数とグローバルデータにコメントを。」
「悪いコードにコメントをつけるな、書き直せ。」
異例な部分やひょっとしてわかりづらいかもしれないような部分には必ずコメントをつけるべき。
コードよりコメントに比重が置かれているようなら、おそらくコードを修正する必要があるだろう。
否定演算はわかりづらいので避けること。
「コードと矛盾させるな。」
コメントはそれが書かれた時点ではコードと一致しているが、バグが直されたりプログラムが進化してもコメントがほったらかしにされ、その結果コードと一致しなくなるケースがよくある。
コードを変更したら、コメントがまだ正確かどうかをきちんと確認するように。
コメントはコードと一致しているだけではだめで、それに沿っていなければならない。
「あくまでも明快に、混乱を招くな。」
学校では何でもかんでもコメントをつけろと教わるし、プロのプログラマは自分のコードすべてにコメントをつけるように要求されることが多い。
しかしそうしたルールにやみくもにしたがっていると、コメント本来の目的が失われてしまう。
コメントは、コード自体から即座に意図を読み取れないプログラムの部分を解読しやすくするためのものだ。
とにかくできるだけわかりやすくコードを書くこと。そうすればそうするほど必要なコメントは少なくなる。
優れたコードはコメントが少なくて済む。
1.7 なぜ手間をかけるのか
きちんと書かれているコードは読みやすく、理解しやすく、ほぼ例外なく間違いも少なく、無神経に殴り書きされたきり一度も仕上げを施されていないコードより小さくなる可能性も高い。
だらしないコードは悪いコードだ。
大事なポイントは、良いスタイルは習慣の問題だということだ。コードを書き起こす際にスタイルに配慮し、時間をとってスタイルを見直し改善していけば、良い習慣が身につく。そしてそれが自然と出来るようになれば、納期に迫られたとしても、無意識に行うことが出来る。
今よりも優れたコードになるだろう。
1.8 参考文献
良いコードを書くことは良い文章を書くことと共通する点が多い。
■個人的に思ったこと
まずコードありき。コメントがなくても、読めるようなコードがベスト。
コメントは、コード自体から即座に意図を読み取れないプログラムの部分を、解読しやすくするためのもの。
無神経に殴り書きされたきり、一度も仕上げを施されていないコード。恐怖ですね。無知な頃、そういうコードを世に出してしまった記憶がある自分としては、顔から火が出るような思いです。
良いコードを書くことは良い文章を書くことに通ずる。仕上げを施す（清書する）という発想、大事ですね。
