短いコードは良いですか？

コードを短くすることは可読性を向上させますが、コードの読み時間を短くすることが重要です。

表面的な構造

クリアな命名規則と変数名
- メソッドには do を使わない
- あいまいな名前は避ける。例: pop popItem
- メソッド名により多くの情報を追加する

function getPage() {}
// 相手は getPage の実装方法を知らないかもしれません。クローラー？Ajax？
function fetchPage() {}
// Ajax を使って JSON を返すことが明確になります。

より明確な語彙を選ぶ
- send => deliver dispatch announce route
- find => search extract locate recover
- start => launch create begin open
- make => create setup build generate add new compose

かわいさよりも明確さが重要です

tmp 変数でも情報を提供できます。
- tmpNumber
- tmpFile
- tmpUsrData
ループの i, j が意味を持つ場合は適切な名前を付けましょう。例: row col index
具体的なメソッド名を選びましょう。
変数に単位がある場合は、単位を入れましょう。
- startSec
- delayMs
重要なプロパティの変数名
- plainData
- entryptedData
変数のスコープが大きい場合は、より長い（またはより情報を含む）変数名を選ぶ方が良いです。逆に、数行のコードで終わる場合は、他の人がその変数が何をしているかすぐにわかるので、alias を使用しても問題ありません。

誤解されない名前

filter は何をフィルタリングするか、残すか？
min max の接頭辞
ブール値
computeData => より大きな処理を実行する関数のようなもの

一貫したフォーマット

一貫したフォーマットを使用する
類似した外観のコードを調整する
関連するコードは1つのパラグラフにまとめる
コメントの美学

なぜフォーマットが重要なのでしょうか？まず第一に、コードを再度見るとき、少なくとも理解しやすく（または見るのが好きになりやすく）なります。また、コードが何をしているかを理解するのにより少ない時間を費やすことができます。

コード品質ツール

eslint
stylelint

混乱を取り除くためにメソッドを使用する？

特定の作業が混乱している場合、メソッドでラップするべきです。

美しく見せることで消費者を欺くことは人間の性質です（誤解）。他の人を騙せるかどうかは重要ではありません。重要なのは、自分自身を騙すことができるかどうかです。自分自身も尊重しないコードは他の人にも尊重されません。

たとえば：

assert(checkTime("12:00")) === "12:00"
assert(checkName("kalan", 20)) === { name: "kalan", age: 20 }
assert(checkPaid(20000, true)) === 20000

上記のコードを注意深く見ると、同じことをしていることがわかりますし、重複する文字列もあります。また、長すぎて何をしているかを理解するには時間がかかります。

この場合、リファクタリングが必要です。メソッドでラップすることができます。

function checkValue(type, value) {
  if (type === "time") {
		assert(checkTime(value));
  }

  if (type === "name") {
    assert(checkName(value) === value;
	}

	if (type === "paid") {
		assert(checkPaid(value)) === value;
	}
}

// checkValue(type,    value);
//  					[string] [depend]
checkValue("name", kalan);
checkValue("time", 12:00);
checkValue("paid", 20000);

これにより、コードが簡潔になり、可読性も向上します！再度強調しますが、コードが短くなることが良いコードを意味するわけではありません。理解しやすいコードこそが良いコードです。これに加えて、以下の利点もあります：

テスト部分が明確に表示されます。
他のテストを追加するのがより簡単になります！

順序と段落の区別：

長いコードは他の人だけでなく、自分自身も見ることを望まないものです。変数の宣言やステートメントの表現において、行動に応じて分割することができます。これは記事を書く際にも同じです。

function getUserInfo(userName, age) {}

getUserInfo("kalan", 20)

// getUserInfo(userName, age)
// 					  [string]  [number]
getUserInfo("kalan", 20)

同じ関数呼び出しの場合は、パラメータを整列させて読みやすくすることができます。


command = {
	{ "timeout"      ,   null,     cmd_spec_timeout},
	{ "timestamping" ,   bull,     cmd_adj_boolean},
f
}

コメントを書く場合、あまり神経質になる必要はありません。その時の考えや、この関数が何をするべきかを書くだけで十分です。しばらくすると、この関数が何をしているかを忘れることがあります。

#2. コメントの章：

コメントは他の人がプログラマーの考えを理解するために存在します。同時に、自分自身が自分自身の考えを理解するためにも存在します。

良いコメントの書き方と、コメントを書く必要のないもの
コメントすべきでない部分
読者の立場に立って考える

コメントがコードの場所を奪わないようにしましょう

抵抗感を書くことを避けましょう。これは通常、時間がかかるまで理解できないことです。ただし、プロジェクトの構造が複雑になる前に、早めにコメントを書くことは絶対に良いことです。そうしないと、あなたは良心に反するコメントを書き残すだけです。

// TODO: refactor

そして、その後には何もありません。

結論

特定のスタイルの選択理由
コードの欠陥
ユーザーが疑問に思う可能性のある部分

コメントを簡潔に保つ

コードをより正確に説明し、パラメータに代名詞を使用しないようにしましょう。
パラメータの動作が複雑な場合は、例を直接提供して使用者がすぐに理解できるようにしましょう。

#3. フロー制御：

最も一般的なのは、if/else の条件判定です。本書では、確定的な条件文を先頭に配置し、単純な状況を最初に処理するというガイドラインが提供されています。関数/メソッドに戻り値がある場合は、できるだけ早く return させましょう！

デモルガンの法則を活用する：この法則は、比較的複雑な論理判断を簡素化することができます。

複雑な論理との戦い：

本書では興味深いアプローチが紹介されていますので、記録しておきたいと思います。 range の実装の場合、range の間に重複があるかどうかを判断する overlapWith というメソッドがあるかもしれません。直接 range の重複を比較するよりも、range の重複がないかどうかを比較する方が簡単です。なぜなら、2つのケースを比較すれば良いからです。=> other の end が range よりも前にあるかどうか。other の start が end よりも後にあるかどうか。

複雑な式を変数に格納する。

$(".thumb_up").removeClass("highlighted")
$(".thumb_up").removeClass("highlighted")
$(".thumb_up").removeClass("highlighted")

// refactor

const $thumbUp = $(".thumb_up")
const highLight = "highlighted"

$(".thumb_up").removeClass("highlighted")
$(".thumb_up").removeClass("highlighted")
$(".thumb_up").removeClass("highlighted")

//

4. 変数：

変数が長く存在するほど、デバッグが困難になります

不要な変数宣言を減らす。

何が不要な変数ですか？

意味をより簡潔にすることができない
ロジック自体が複雑でなく、変数で置き換える必要がない
1回しか使用しない

1回の書き込みのみの変数を使用する

関数型プログラミングでは、関数が純粋で不変であることを望みます。変数にも同様であり、変数は const や不変にするようにしましょう。これにより、関数に対する理解が容易になるだけでなく、エラーの原因が把握しやすくなります。

アイデアをコードに変換する：

まず、口頭で行動を説明し、それからプログラムの動作をコードに変換します。これにより、プログラマーはより自然なコードを書くことができます。

不要なコードを書かないようにする

要件を理解する
要件を再考する
標準ライブラリに精通するために定期的に API を読む

カランのブログ

【メモ】読みやすいコードの美学