MyEnigma

とある自律移動システムエンジニアのブログです。#Robotics #Programing #C++ #Python #MATLAB #Vim #Mathematics #Book #Movie #Traveling #Mac #iPhone

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』

1章

コードは短くしたほうがいい。

だけど、理解するまでにかかる時間を短くすることは大切だ。

関数名につけるgetはあまり明確な単語ではないので、

可能ならもっと明確な名前にする。


2章

イテレータが複数ある時には、インデックスにもっと明確な名前をつける。

i,j,kではなく、club_i,member_i,users_iなど。

またはci,mi,uiでもよい。配列の名前の最初の文字を同じになるようにする。


変数や関数の名前は短いコメントのようなものである。

時間やバイトのように計測できるものであれば、変数名に単位を入れるべき。

例) start_ms, size_mb,degrees_cw


3章

スコープが小さければ短い名前で良い。

長期休暇よりも短期でどこかへ行くときの方が荷物は小さいはずだ。


クラスのメンバ変数の後ろには_をつける。

例)member_

filterやlength,limitなどは明確ではないため、別の単語を使う。

filter->selet, exclude

length-> max_chars, words


4章

計算コストが高い関数名にはcomputeを使う。

ブール値の変数名の頭にはis,has,can,shouldなどを使う。

プログラミングのほとんどの時間はコードを読む時間である。

複数のコードブロックで同じようなことをしていたら、

同じように見えるようにする。

コードの縦をわかりやすいように整列させる。

同じ関数でも、空行を使ってコードを段落でわける。


5章

コメントを読むとその分だけコードを読む時間がなくなるので、

無駄なコメントは書かない

TODOや、試行錯誤の結果などをコメントに書く

ハードコードした定数には、その値にした理由をコメントとして書く

嵌りそうな事柄があればコメントを残す

すぐれたコメントより、優れたコードを書く

ファイルやクラスには全体像のコメントを書く


6章

関数のコメントには入出力の実例を書くと良い

引数に名前を付けてしまう。

インラインコメント例

void Connect(/*timeout_ms = */ 10, /*use_encryption = */ false);

brute force: 力ずくで


7章

条件式の左側は変化するもの、右側はあまり変化しないもの

do whileはコードをわかりにくくするので、避ける

関数では、必要無いときは早くreturnで返す

ネストはできるだけ深くしない。


8章

ド・モルガンの法則で無駄な条件式を無くす

長い文は、変数(説明・要約変数)を使って短くする。

if文の条件文を二行以上にしない。

クラスのメソッドをstatcにできるだけすると、

そのメソッドはメンバ変数とは関係無いとわかりやすくなる。

できるだけ変数のスコープは短くする。

変数はできるだけ使用する位置の近くで宣言する。

変数はできるだけ、変更されないような構造にする。


10章

エンジニアリングとは、大きな問題を小さな問題に分割して、

それぞれの解決策を組み立てることに他ならない。


自己完結しており、自分がアプリケーションに

どのように使われているかを知らないコードは関数にできる。

printf用の文字列整形プログラムも関数にできる。

重要なことは、プロジェクト固有のコードから汎用コードを分離することである。


11章

読みにくいコードがあれば、その中で実施しているタスクを列挙し、
コードをそのタスクを一つ一つ実施するように分割する。

12章

やりたいことを言葉で書いてから、コードにするとコードが簡単になる。

Code Completeでも同じことを言っている

myenigma.hatenablog.com


13章

要求を考えて、できるだけコードを書かないようにする。

コードをできるだけ軽量にする方法
1.汎用的なユーティリティコードを作る
2.未使用のコードを削除する
3.プロジェクトをサブプロジェクトに分割する。

標準ライブラリが常に使えないかどうかを考える。

標準ライブラリのマニュアルを一通り目を通して見る。

平均的なソフトウェアエンジニアが一日に書く出荷用コードは10行


14章

テストコードは、

実際のコードの使い方を表すことができるので、できるだけわかりやすく書く

やりたいテストを一度文章にすると、テストコードで重要な部分がわかる。

エラーメッセージはできるだけわかりやすいようにする。

assert関数にも色々あるため、できるだけわかりやすいものを使う。

グローバル変数があるとテストしずらくなる。

それぞれのクラスは疎結合していた方がテストしやすい。

テストのカバレージを100%にすることに力を注ぎすぎてはいけない。

15章

 
getがついている関数は計算コストが低いものとする。

(ただのメンバ変数のデータを取得する感じ)

MyEnigma Supporters

もしこの記事が参考になり、

ブログをサポートしたいと思われた方は、

こちらからよろしくお願いします。

myenigma.hatenablog.com