比較短いコードは良いのか？

コードを減らすことで可読性が向上しますが、重要なのはコードを読む時間を短縮することです。

表層構造

1. 明確な命名法と変数名
   • メソッドに do を使う必要はありません
   • 曖昧な名前は避けること、例: pop popItem
   • メソッド名により多くの情報を追加する

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

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

明確さが可愛さよりも重要です

3. tmp 変数であっても、もう少し情報を提供できます。

   • tmpNumber
   • tmpFile
   • tmpUsrData

4. ループの i,j に意味がある場合は、適切な名前を付けます。例: row col index

5. 具体的なメソッド名を選択します。

6. 変数に単位がある場合は、単位を含めます。

   • startSec
   • delayMs

7. 重要な属性の変数名

   • plainData
   • entryptedData

8. 変数の作用範囲が広い場合は、より長い（または情報が多い）変数名を使用することが良い選択です。一方、数行のコードで終了し、他の人がその変数が何をしているかすぐに理解できるなら、alias を使っても問題ありません。

誤解を招かない名前

1. filterは物をフィルタリングするのか、それとも残すのか？
2. min max プレフィックス
3. ブール値
4. computeData => より重い関数を実行しているように見える

レイアウトの一貫性

1. レイアウトの一貫性を保つ
2. コードの類似した外観を調整する
3. 関連するコードを一つの段落にまとめる。
4. コメントの美学

なぜレイアウトがそれほど重要なのか？他の人（またはあなた自身）が後でコードを見るとき、少なくとも理解しやすく（そして見る気になる）なるからです。また、コードが何をしているのかを理解するのにかかる時間が少なくて済むので、何の得がないでしょうか？

コード品質ツール

• 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},
}

コメントを書く際には、あまりこだわらず、自分が当時考えていたことや、この関数が何をすべきかを書き留めておけば大丈夫です。時間が経つと、この関数が何をしていたのかを忘れてしまうことがあります。

--

#2. コメントについて：

コメントは、他の人がプログラマーの考えを理解できるように存在します。同時に、自分自身が当時の考えを理解する助けともなります。

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

コメントがコードのスペースを奪わないようにする

書くことへの抵抗を避ける。これは通常、少し時間がかかります。しかし、プロジェクトの構造が複雑になる前に、できるだけ早くコメントを書くことは絶対に良いことです。そうしなければ、あなたはただ「// TODO: refactor」と書くだけになり、それ以降は何も進展しないでしょう。

結論

• 特定の書き方を選ぶ理由
• コード内の欠陥。
• ユーザーがどの部分で疑問を感じるか

コメントを簡潔に保つ

• より正確な方法で自分のコードを説明し、パラメータを代名詞で説明しない。
• パラメータの動作が複雑な場合は、直接例を示してユーザーに一目で理解してもらう。

#3. フロー制御：

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

• デモルガンの法則を適切に活用する：この法則は理工系の人には印象があるはずです！これは、複雑な論理判断を簡素化することができます。

複雑な論理に立ち向かう：

本書では、非常に興味深い方法が紹介されており、記録しておきたいと思います。 range を実装する際に、overlapWith というメソッドがあり、2つの range の間に重なりがあるかどうかを判断します。直接この2つの range が重なっているかを比較するよりも、この2つの range が重なっていないかを比較する方が簡単です。なぜなら、2つの条件を比較すれば良いからです => other の end が range の前にある。other の start が end の後にある。

複雑な式を変数で包む。

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

// リファクタリング

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

$(".thumb_up").removeClass(highLight)
$(".thumb_up").removeClass(highLight)
$(".thumb_up").removeClass(highLight)

4. 変数：

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

• 不必要な変数宣言を減らします。

不必要な変数とは何か？

1. 意味をより簡潔にすることができない
2. 本体のロジックが複雑でない場合、変数に置き換える必要がない
3. 一度しか使用しない

• 一時的な変数を使用する

関数型プログラミングでは、関数は純粋で不変であることを望んでいます。変数についても同様で、できるだけ変数を const または immutable にしてください。これにより、関数の内容を一目で理解でき、エラーが発生しやすい箇所をより把握しやすくなります。

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

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

不必要なコードを書くことを避ける

• 要求を理解する
• 要求を再考する
• 定期的に API を読み、標準ライブラリに対する親しみを維持する