Help us understand the problem. What is going on with this article?

リーダブルコード  まとめ

More than 1 year has passed since last update.

リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック
を読んだのでまとめと感想文。

読んだ本概要

リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック
【著者】
Sustin Boswell
Trevor Foucher
【出版】
オライリー・ジャパン

読みやすさの基本定理

他の人がコードを理解するのにかかる時間を最短なコードが良いコード。
理解するというのは、読んでバグを指摘できるレベルの理解。

表面上の改善

名前は短いコメント

多くの情報を与えられる名前をつける。

誤解を与えない名前をつける。

  • 明確な単語
  • 汎用的な名前は避ける
  • 具体的な名前を使う
  • 単位を付けたり、与える処理を付けたりする
  • スコープの大きな変数には長い名前を付ける
  • 大文字、アンダースコアなどを法則をつけて使う

具体案

get:fetch,dounload
size:height,numnodes,memorymytes
stop:kill,resume,pause
send:deliver,dispatch,announce,distrubute,route
find:search.extract,locate,recover
start:launch,create,begin,open
make:create,set up,build,generate,compose,add,new
i,j,k,iter,イテレータ:members_iのように名前をつける
単位のある変数:_ms,_kbps,_mbのように単位をつけておくとわかりやすい。
エンティティごとに異なるフォーマットを変更する
限界値:min,max
範囲指定:first,last,begin,end
bool値:否定形は使わない。頭にis,has,can,shouldを使う。

余白・配置・順序を使って読みやすくする。(シルエットを整える)

  • 読み手が慣れているパターンと一貫性をもつ。
  • 似ているコードは似せて見せる。
  • 関連するコーデはまとめてブロックにする。(いい感じに区切るための改行とかを入れる)
  • 順序に意味をつける(重要順とか)

コメントの意義

  • 余計なコメントはつけない
  • コードを書いている時の考えをコメントする
  • なにこれ?ってなりそうなトラップとかにコメントする
  • コードを理解するための役に立つことを書く

ループとロジックの単純化

コードを読む人が戻ったり止まったりしないコードを書く。
自分のコードの行を短くするよりも読み手が考える時間を短くすることを優先する。

if-else

- 条件は否定形よりも肯定形を使う
- 単純な条件を先に持ってくる
- 主張が強そうな条件を先に持ってくる
- 3項演算子、do-while、gotoは使わない。(行数が減って明らかにわかりやすくするときにだけ使う。)
- ネストは浅くする。(早めにreturnするか、continueする)
- 条件文は、変化する値を左、決まった値を右におく。

コンパクトな式にする

一行が長くなってしまう式なコンパクトに分解する。

  • 説明変数・要約変数を使う(条件式をまとめた変数を作る)
  • ド・モルガンを使って簡略化する assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());←こういうのはだめ。わかりにくい。

変数の使い方

変数の多さ、スコープによってわかりやすさが変わる。

  • 一時的にしか使わない変数は邪魔。
  • 制御フロー変数を使わない。breakとかをうまく使う。
  • グローバル変数は名前空間を汚す。スコープがすぎたらその変数を忘れてしまえるようにする。
  • 言語によってスコープが違うので注意。
  • 定義するのは、読みやすいように直前で。

コードの再編成

無関係の下位問題をみつける

  • 高レベルの目標に直接的に関係がない下位問題を解決するためのコードは別関数として切り出す。
  • プロジェクト固有のコードから汎用のコードは切り出す。
  • やりすぎない程度に。

一度にひとつのことをする

  • 様々な処理をいっぺんに行うコードは書かない

コードに思いを込める

相手に理解できるように書くことが必要
- 簡単な言葉で同僚にもわかるように書く
- 説明の中で使っているキーワード、フレーズに注目する
- 説明に合わせてコードを書く

問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ

短いコードを書く

もっとも読みやすいコードは何も書かれていないコード
- もっとも簡単に課題を解決できるコードを書く
- 不必要な機能はもたない。
- 標準ライブラリに慣れ親しんでおく・・・

選抜テーマ

テストと読みやすさ

テストコードコードを読みやすくすることはテスト以外のコードを読みやすくするのと同じくらい大事。他のプログラマが安心してテストを追加できるようにテストコードも読みやすくしておく。
- 大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする。
- テストの本質は、状況+入力→振る舞い+出力なので、だいたいシンプルにまとまる。
- エラーメッセージは役に立つよう、わかりやすくする。
- テストに使う関数、ファイル名はちゃんと名前をつける。(テストするクラス・関数・状況・バグとか)
- テスト容易性を高める。(グローバル変数を使わない。多くの外部コンポーネントに依存しない。コードが決定的な動きをする。)

時間カウンタを実装する

ベルトコンベアー設計

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした