2
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

JavaScriptにおけるクリーンコード設計:読める・変えられる・壊れないコードの原則と実践

Posted at

概要

クリーンコードとは、「読む人」にとって明確な構造を持ち、予測可能かつ修正しやすいコードである。
技術的な正しさではなく、構文と設計に「意味と意図」が現れているかが重要となる。

本記事では、以下の視点から JavaScript におけるクリーンな設計を体系化する:

  • 意図を伝える変数・関数命名
  • 関数の単一責務と分割
  • ネストとフロー制御の最小化
  • 副作用の分離
  • 条件式の明示化
  • “直感的に読める構造”のデザイン戦略

1. 意図を表す変数・関数名

// ❌ NG
let d = new Date();
let t = d.getTime();

// ✅ OK
const now = new Date();
const timestamp = now.getTime();
  • ✅ 名前で型を表す(count, isVisible, userList など)
  • ✅ 抽象名でなく「意味のあるラベル」にする
// ❌ doStuff() ❌ handleData()
// ✅ parseResponse(), updateUI(), fetchUserList()

2. 関数は“何をするか”が一文で言えるか

// ❌ Bad: 複数責務を持つ関数
function validateAndSubmit(formData) {
  if (!formData.name) throw Error();
  // ...
  sendToServer(formData);
}

→ ✅ validate()submit() に分離すべき


3. ネストの制御と早期リターン

// ❌ 多重ネスト
function process(user) {
  if (user) {
    if (user.active) {
      return save(user);
    }
  }
  return null;
}

// ✅ フローを明示
function process(user) {
  if (!user || !user.active) return null;
  return save(user);
}

4. 副作用を分離する

// ❌ 副作用を含んだ処理
function addItemAndUpdateUI(item) {
  list.push(item);
  renderList(); // UI更新(副作用)
}

→ ✅ 純粋関数と副作用の分離

function addItem(list, item) {
  return [...list, item]; // 不変性 + 副作用なし
}

5. 条件式は“読む人の頭の中”を助けるために書く

// ❌ 意味が不明
if (!x || !y && z) {}

// ✅ 意図が明確
const isValid = !x || (!y && z);
if (isValid) {}
  • ✅ 「条件に名前をつける」ことで思考負荷を下げる

6. 魔法の数値・文字列を排除する

// ❌ Bad
setTimeout(fn, 3000);

// ✅ Good
const THREE_SECONDS = 3000;
setTimeout(fn, THREE_SECONDS);

→ ✅ 意図が見える → 修正も簡単


7. 構造を“見れば理解できる”ようにする

function fetchUserData(id) {
  return fetch(`/api/users/${id}`)
    .then(res => res.json())
    .then(user => {
      updateUserUI(user);
      return user;
    });
}
  • ✅ 関数名と処理の流れが一致
  • ✅ promiseチェーンを明確に順序づけ
  • ✅ UI更新が副作用として明示されている

8. “短い関数”が正義ではない

// ❌ 分割しすぎて読めない
renderUI();
updateState();
logResult();

// ✅ コンテキストが伝わる関数構造
function submitApplication() {
  validateInput();
  sendRequest();
  showSuccessModal();
}

→ ✅ 関数の“長さ”より、“意図”を伝える構造が優先


クリーンコードの設計判断フロー

① この関数は「何をする関数か」が一文で言えるか?

② 名前を見ただけで型と意味が分かるか?

③ ネストが深くなっていないか?早期returnは可能か?

④ 状態変更・副作用が予測しやすい位置にあるか?

⑤ 条件・ループの意図が読み取れるか?

⑥ 数値や文字列に“意味の名札”をつけているか?

⑦ コード全体が“読むことに抵抗を感じない”か?

結語

クリーンコードとは、「構文を正しく書くこと」ではない。
それは「読む人が何も考えずに理解できるように書く」ことである。

  • 意図を名前に刻む
  • 情報の流れを整理する
  • 状態と副作用を分離する
  • 読む人を迷わせないために“設計する”

良いコードは、黙っていても伝わるドキュメントである。
それがクリーンコードの本質である。

2
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?