[コーディング] リーダブルコードを読んで

リーダブルコードより(内容があれなら削除します)

良いコードとは　

• 短いコードである
  ->しかし短ければ良いわけではなく、他人が短時間で理解しやすいことが重要である。

/* 条件分岐で{}をなくしたりすると読みにくい。けど、簡潔になる。規則などにも依るだろうが、永遠の課題なんじゃないかぁとか思ったり。ちなみにMSの.netのサンプルではifとelseにも{}がついていないところがあった。(もっともC#では{}は改行してから書くことが多いのでそんなに気にならない笑)*/

命名法

• 明確な名前をつける
• プレフィックス、サフィックスを用い情報を追加する
• 具体的な名前にする
• スコープの大きな変数には長い名前をつける
• 大文字やアンスコなどには意味を持たせる

例）
make : 何かを作るのだろうが、少し曖昧
　-> create, setUp, build, generate, compose, add, new
　このようにニュアンスが含まれている単語にすると伝わり易い。

start : getTime()等時間を取得した時で考える
　-> getTime()でミリ秒が返ると考えると、start_msにした方がよい。

BackEndManagerをBEManagerのように頭文字や省略形を使うと途中参画のメンバーにはわかりづらいので非推奨。

ConvertToStringをToStringにしても意味は損なわれないので、意味が変わらなければ省略することは正。

クラス名はCamelCaseにし変数名はsnake_caseというように規則を決める　　

length : 長さ、数など色々考えられる(バイト数、文字数、単語数等)
　->例えば最大文字数ならばmax_charsにするとわかり易い。

getXXX() : getXXXだとアクセサのように感じてしまう。これがもし1万回イテレートするようなメソッドの場合のコストが高くなるので、低コストな実装にするかメソッド名を変更した方がよい。

/* こここそ現場の命名規則で決められそうだが、コードレビューをしてもらうと、なるほどなーっていう時がすごく多い。(感性の差があるからなんとも言えない時もあるけど。) */

美しさ

• 複数のコードブロックで同じようなことをしていたらシルエットも同じようにする
• コードの列を整列すれば概要が把握しやすくなる。誤字脱字が減る
• A,B,Cで並んでいたものを他の場所でB,A,Cのように並び替えず常に順番を守る
• 空行を使って大きなブロックを論理的な段落に分ける

/* 細かいところまで整頓してる人もいれば、レベルだけ合わせる人もいる。難しいところだが、上記の点を意識していれば無難そう */

コメント

• コードを眺めてすぐにわかる内容にはコメントしない
• メソッド名で処理内容がイメージがわかないならメソッド名を変更する
• 自分の考えを残す
• コードの欠陥にコメントする

• 定数にコメントをつける(定数は理由があることが多い)
• ハマりそうな箇所にコメントする(後の人に注意する)
• メソッドなどには要約をつけるのもよい

/* 先ほどから書いているが、こんな感じで思いついたのをメモるのが大事。コメっていらんなら消せばよい。自分が作ったは自分のエゴであり、すぐには伝わらない。生活でも同じ。阿吽の呼吸はすぐにはできない */

コメントは簡潔に

• 指示代名詞は避ける
• “行を数える”は改行が含まれるのかなど曖昧
• コーナーケースの実例を書いてしまう
• 名前付き引数を渡せない言語ならコメントをつけて関数を呼び出す
  Connect(/* timeout_ms = */ 3600, /* use_encryption = */ true);

ロジックの単純化

• 条件やループは”自然”にする。読み手が止まらないように
• 条件式の左右でも気持ち悪さがある

• 条件式には否定形より肯定形を使う(elseに否定がいくほうがよい)
• 単純な条件を先に書く.
• コードが簡潔になるのならば三項演算子はok
• do-whileやgotoは極力使わない
• 返せるならばreturnですぐに返す
• ネストは浅くする。早めに返す、ループ内部のネストを削除する等
• 巨大な式は分割する
• 条件式にメソッドなどを使って長く読みづらくなるなら、変数にいれてしまう(変数名は式を説明するような名前にする)

/* 言われてみれば左辺と右辺はそうしている気がする。考えたことはなかったが、慣れと常套句な感じでした。これからは後輩にしっかい教えられそう笑
条件式に式を入れた方がかっこいいだろ〜。短い方がいいんだろう〜って初めは思うことかもしれない。でも。変数に入れた方が自分も相当楽になる気がするんだが。。。仕事で無意味なかっこよさはいらない */

変数の読みやすさ

• 不要な変数を削除する
  ->式の結果を式にいれて、中間結果の変数を削除する
• 変数のスコープを極力小さくする
  ->メンバ変数をローカル変数にしたりstaticつけたりJSならvarをつけたり　　
• 一度だけ書き込む変数を使う
  ->一度しか使わない、イミュータブルにするなど

/* これはたくさん使うだろう！！！！と思ってメンバ変数にして、結果2回しか使わない時があるw めんどくさがってそのままにしたことがある。。。笑 リリースの際にはしっかりとスコープ等を考えよう */

コードの再構築

• プロジェクト固有のコードから汎用のコードを分離させる　　
  ->ユーティリティコード、ヘルパー関数、ライブラリを作成
• 1処理1タスク
  ->読みにくいコードは分解して別々のコードにしていく
• 難しいコードを使わずに簡単なコードで書く(口語で簡単に説明するような。ラバーダッキング)
• 短いコードを書く
  • 不要な機能を削除する
  • 最も簡単に問題を解決できるような要求を考える
  • ライブラリを使う(慣れておく)

/* 新入社員,初心者の方はここが大事。私も何回もダメ出しをくらったが、1処理1タスク。ネストが深くなりすぎなければよいだろう、、、と思って1メソッドに詰め込んで指摘されたり、変にヘルパー関数化して、無駄って言われたり。一つ一つシッカリと書いていけばいいんです */

テスト

• トップレベルはできるだけ簡潔にする。入出力のテストは1行でできたらいい
• バグの発見や修正がし易いようなアラートを出力するようにする
• 有効な値のうち、最も単純な入力値を使う
• テスト関数は長くても良いので、Test_関数名_状況のように説明的な名前にする

/// 『リーダブルコード』を読んでの感想？です
/// それが全てではないにせよ、開発現場に出て少しコーディングし始めた
/// というくらいの時に読むのが良いのかなって思います。
/// この記事は抜粋なので、分かりづらいですが、本にはしっかりサンプルがあり
/// とても面白おかしく読み進めます。