Lesson 0.4.4 — Guard Clauses & Early Return

Bài 0.4.4 — Guard Clauses & Early Return

Viết code phẳng, tránh nesting sâu • 25 phút

0.5×0.75×1.0×1.25×1.5×2.0×0:00 / 0:00

0. Metadata (Thông tin bài học)

Field	Value
Stage	0 — JavaScript Language Foundation
Module	0.4 — Operators & Control Flow
Lesson	0.4.4 — Guard Clauses & Early Return
Competency	C01.4 — Control Flow
Depth	L3 (Use)
Prerequisites	0.4.1 Operators, 0.4.2 Conditional Logic, 0.4.3 Short-circuit Evaluation
Estimated Cognitive Load	Medium

1. Why This Exists (Vì sao cần học)

Bạn mở một file production và thấy đoạn code sau:

function processOrder(order) {
  if (order) {
    if (order.items) {
      if (order.items.length > 0) {
        if (order.status === "pending") {
          // ... 20 dòng logic chính
        } else {
          return "Order not pending";
        }
      } else {
        return "No items";
      }
    } else {
      return "Invalid order structure";
    }
  } else {
    return "No order";
  }
}

Mỗi lần đọc, bạn phải "đi sâu" vào từng lớp if để tìm logic chính. Đây gọi là "pyramid of doom" — code lồng nhau như kim tự tháp.

Lesson này dạy bạn một pattern đơn giản nhưng mạnh mẽ:

Kiểm tra điều kiện lỗi ngay đầu hàm, return sớm, để phần còn lại là "happy path" phẳng lì.

Đây là bước đầu tiên trong curriculum đưa bạn từ "viết code chạy được" sang "viết code người khác đọc được".

Preview

Bạn sẽ học cách đảo ngược điều kiện — thay vì "nếu đúng thì làm", bạn sẽ viết "nếu sai thì thoát". Kết quả: logic chính nằm phẳng ở cột trái, không bị thụt vào nhiều cấp if.

2. Prerequisites (Yêu cầu đầu vào)

Trước khi học lesson này, bạn phải:

• [ ] Viết được if/else cơ bản (0.4.2).
• [ ] Hiểu return trong function (0.5.1).
• [ ] Biết && và || hoạt động như thế nào (0.4.3).
• [ ] Hiểu undefined, null, và truthy/falsy (0.3.1).

Nếu thiếu một trong các kỹ năng trên, quay lại lesson tương ứng trước.

3. Learning Objectives (Mục tiêu học tập)

Sau lesson này, bạn có thể:

1. Nhận diện "pyramid of doom" trong code thực tế.
2. Refactor nested if/else thành flat guard clauses + early return.
3. Giải thích tại sao flat structure dễ đọc hơn nested structure.
4. Phân biệt khi nào early return phù hợp và khi nào không.
5. Kết hợp short-circuit với guard clauses để viết validation ngắn gọn.

4. Mental Model (Mô hình tư duy)

Hãy hình dung một hàm như một tòa nhà có nhiều cửa kiểm soát:

[ CỬA BẢO VỆ - GUARD CLAUSES ]

(Cửa 1) order tồn tại?
  ├── KHÔNG ─► RETURN ngay
  └── CÓ    ─► Đi tiếp

(Cửa 2) items tồn tại?
  ├── KHÔNG ─► RETURN ngay
  └── CÓ    ─► Đi tiếp

(Cửa 3) items.length > 0?
  ├── KHÔNG ─► RETURN ngay
  └── CÓ    ─► Đi tiếp

(Cửa 4) status === "pending"?
  ├── KHÔNG ─► RETURN ngay
  └── CÓ    ─► Đi tiếp

        │
        ▼

[ HAPPY PATH - LOGIC CHÍNH ]
  └─► Code chạy phẳng ở ngoài
  └─► Tránh hoàn toàn bẫy lồng if (Arrow Anti-Pattern)

Điểm then chốt

Guard clause không phải là "viết nhiều return để khoe". Nó là đảo ngược điều kiện — thay vì hỏi "nếu A thì làm B", bạn hỏi "nếu không A thì thoát".

// Nested (pyramid)
if (valid) {
  // logic chính
}

// Guard (flat)
if (!valid) return;
// logic chính

5. Core Concepts (Các khái niệm cốt lõi)

Essential (Bắt buộc)

Khái niệm	Ý nghĩa
Guard Clause	if ở đầu hàm kiểm tra điều kiện lỗi/edge case, return sớm
Early Return	return xuất hiện trước khi hàm kết thúc tự nhiên
Happy Path	Luồng logic chính, không có lỗi, không bị lồng trong if
Pyramid of Doom	Code if lồng nhau nhiều tầng, khó đọc và khó maintain

Supporting (Hỗ trợ)

• Fail Fast: phát hiện lỗi càng sớm càng tốt, không để lỗi "chảy" xuống logic chính.
• Single Level of Abstraction (SLA): mỗi hàm nên ở một mức độ trừu tượng, guard clause giúp giữ happy path ở cùng một level.

Awareness (Biết tồn tại)

• Optional chaining ?. (Stage 2): sẽ giúp guard clause ngắn hơn.
• Assertion functions (TypeScript, Stage 6): dạng guard clause có type narrowing.

Out of Scope (Không học trong bài này)

• Exception handling (throw/try/catch) — sẽ học ở 0.7.3.
• Type narrowing với guard clauses — thuộc Stage 6.
• Design pattern phức tạp như Strategy pattern.

6. Worked Example (Ví dụ phân tích từng bước)

Ví dụ: Xử lý đơn hàng

Bước 1 — Code gốc (pyramid):

function calculateTotal(order) {
  let total = 0;
  if (order) {
    if (order.items) {
      if (order.items.length > 0) {
        for (const item of order.items) {
          if (item.price && item.quantity) {
            total += item.price * item.quantity;
          }
        }
        return total;
      } else {
        return 0;
      }
    } else {
      throw new Error("Invalid order");
    }
  } else {
    throw new Error("No order");
  }
}

Bước 2 — Phân tích vấn đề:

• Logic chính (tính tổng) nằm sâu bên trong 4 lớp if.
• Mỗi lần đọc phải "nhớ" các điều kiện bên ngoài.
• else ở cuối cách xa if tương ứng — khó ghép nối.

Bước 3 — Đảo ngược điều kiện thành guard clauses:

function calculateTotal(order) {
  if (!order) throw new Error("No order");
  if (!order.items) throw new Error("Invalid order");
  if (order.items.length === 0) return 0;

  let total = 0;
  for (const item of order.items) {
    if (!item.price || !item.quantity) continue;
    total += item.price * item.quantity;
  }

  return total;
}

Bước 4 — Quan sát kết quả:

• Happy path (vòng lặp tính tổng) nằm ở cột trái, không bị thụt vào.
• Mỗi guard clause độc lập — đọc từng dòng là hiểu, không cần nhớ context bên ngoài.
• else biến mất hoàn toàn.

Code Review Lens

Khi review code, nếu thấy logic chính bị thụt vào quá 2 cấp if, hãy hỏi: "Có thể đảo ngược điều kiện thành guard clause không?"

7. Prediction Exercise (Bài tập dự đoán)

WARNING

Đừng chạy code. Đoán output và giải thích flow thực thi.

Câu 1

function check(value) {
  if (!value) return "empty";
  if (value.length < 3) return "too short";
  if (value.includes("!")) return "has bang";
  return "ok";
}

console.log(check("hi!"));

Dự đoán của bạn:

• Output?
• Hàm dừng ở guard clause nào?

Câu 2

function process(data) {
  if (data) {
    if (data.value) {
      return data.value * 2;
    }
  }
  return 0;
}

// Refactor thành guard clause. Dự đoán output vẫn giữ nguyên?

Dự đoán của bạn:

• Refactor thành guard clause như thế nào?
• Output của process({ value: 5 })?
• Output của process(null)?

Câu 3

function greet(user) {
  if (user) {
    if (user.name) {
      if (user.name.length > 0) {
        return "Hello " + user.name;
      }
    }
  }
  return "Hello Guest";
}

Dự đoán của bạn:

• greet({ name: "" }) → ?
• greet({ name: "Alice" }) → ?
• greet(null) → ?

[Đáp án & Giải thích]

Câu 1:

• Output: "has bang"
• Hàm dừng ở guard clause thứ 3 (value.includes("!")).
• Flow: "hi!" truthy → length = 3 (không < 3) → contains "!" → return "has bang".

Câu 2:

• Refactor:

  function process(data) {
    if (!data || !data.value) return 0;
    return data.value * 2;
  }

• process({ value: 5 }) → 10
• process(null) → 0 (guard clause !data trigger)

Câu 3:

• greet({ name: "" }) → "Hello Guest" (vì "" có length = 0, không vượt qua guard name.length > 0)
• greet({ name: "Alice" }) → "Hello Alice"
• greet(null) → "Hello Guest" (guard !user trigger)

8. Implementation Lab (Bài lab thực hành)

Level 1 — Guided (Hướng dẫn)

Refactor đoạn code sau dùng guard clauses:

function getDiscount(user) {
  if (user) {
    if (user.isMember) {
      if (user.memberSince) {
        return 0.2;
      }
    }
  }
  return 0;
}

[Gợi ý]

function getDiscount(user) {
  if (!user) return 0;
  if (!user.isMember) return 0;
  if (!user.memberSince) return 0;
  return 0.2;
}

Level 2 — Partial Scaffold (Khung mẫu)

Hoàn thành hàm validateInput bằng guard clauses. Yêu cầu:

• Nếu input là null/undefined → throw "Input required"
• Nếu input không phải string → throw "Input must be string"
• Nếu input.length < 5 → throw "Input too short"
• Nếu input.length > 100 → throw "Input too long"
• Nếu input chỉ chứa khoảng trắng → throw "Input cannot be empty"
• Happy path: return "Valid"

function validateInput(input) {
  // Guard 1: null/undefined
  // Guard 2: type
  // Guard 3: min length
  // Guard 4: max length
  // Guard 5: whitespace-only

  return "Valid";
}

// Test
console.log(validateInput("hello world")); // "Valid"
// console.log(validateInput(null)); // throw "Input required"
// console.log(validateInput("   ")); // throw "Input cannot be empty"

[Đáp án tham khảo]

function validateInput(input) {
  if (input == null) throw new Error("Input required");
  if (typeof input !== "string") throw new Error("Input must be string");
  if (input.length < 5) throw new Error("Input too short");
  if (input.length > 100) throw new Error("Input too long");
  if (input.trim().length === 0) throw new Error("Input cannot be empty");

  return "Valid";
}

Level 3 — Independent (Độc lập)

Refactor hàm sau. Giữ nguyên behavior, nhưng loại bỏ tất cả nested if:

function processPayment(payment) {
  let result = "";
  if (payment) {
    if (payment.amount > 0) {
      if (payment.method) {
        if (payment.method === "card" || payment.method === "bank") {
          result = "Processing " + payment.method + " payment of " + payment.amount;
        } else {
          result = "Unsupported method";
        }
      } else {
        result = "No method";
      }
    } else {
      result = "Invalid amount";
    }
  } else {
    result = "No payment";
  }
  return result;
}

[Đáp án tham khảo]

function processPayment(payment) {
  if (!payment) return "No payment";
  if (payment.amount <= 0) return "Invalid amount";
  if (!payment.method) return "No method";
  if (payment.method !== "card" && payment.method !== "bank") return "Unsupported method";

  return "Processing " + payment.method + " payment of " + payment.amount;
}

9. Edge Cases (Các trường hợp ngoại lệ)

Edge 1: Quá nhiều guard clauses

function doSomething(a, b, c, d, e) {
  if (!a) return;
  if (!b) return;
  if (!c) return;
  if (!d) return;
  if (!e) return;
  // ...
}

Tại sao fail: Quá nhiều guard liên tiếp có thể là dấu hiệu hàm làm quá nhiều việc hoặc parameter không có cấu trúc.

Fix: Gom parameter thành object, hoặc tách validation ra hàm riêng.

Edge 2: Guard clause với side effect

function process(user) {
  if (!user) {
    logError("Missing user");
    return;
  }
  // ...
}

Caveat: Guard clause với side effect (log, analytics) vẫn ổn, nhưng đừng để logic phức tạp trong guard. Guard nên đơn giản và nhanh.

Edge 3: Khi nào KHÔNG dùng early return

function allocateResource() {
  const resource = acquire();
  if (!resource) return; // ❌ Resource leak!
  // ... use resource ...
  release(resource);
}

Tại sao fail: Nếu bạn cần cleanup (đóng file, giải phóng resource), early return đơn giản có thể bỏ qua cleanup. Trong trường hợp này, try/finally (0.7.3) hoặc structured pattern khác phù hợp hơn.

Edge 4: else sau guard clause là thừa

function check(x) {
  if (!x) return "no";
  else return "yes"; // ❌ else thừa
}

// Fix:
function check(x) {
  if (!x) return "no";
  return "yes";
}

10. Debug Lab (Bài lab gỡ lỗi)

Symptom (Triệu chứng): Hàm getUserDisplayName trả về kết quả không mong muốn với input hợp lệ.

Reproduction (Tái hiện lỗi):

function getUserDisplayName(user) {
  if (user) {
    if (user.profile) {
      if (user.profile.name) {
        return user.profile.name;
      } else {
        return user.email;
      }
    } else {
      return "Anonymous";
    }
  }
}

console.log(getUserDisplayName({
  email: "alice@example.com",
  profile: { name: "" }
}));
// Actual: "alice@example.com"
// Expected: "Anonymous" (vì name rỗng, user muốn ẩn tên)

Evidence (Bằng chứng):

• Code nested if/else khiến logic name === "" rơi vào nhánh else của user.profile.name.
• Nhánh đó return user.email, không phải "Anonymous".
• Người dùng mong đợi: nếu profile tồn tại nhưng name rỗng → "Anonymous".

Hypothesis (Giả thuyết): Refactor thành guard clause để mỗi điều kiện rõ ràng, và xử lý name === "" như một trường hợp riêng.

Verification (Xác minh):

function getUserDisplayName(user) {
  if (!user) return undefined;
  if (!user.profile) return "Anonymous";
  if (!user.profile.name || user.profile.name === "") return "Anonymous";
  return user.profile.name;
}

console.log(getUserDisplayName({
  email: "alice@example.com",
  profile: { name: "" }
}));
// → "Anonymous" ✅

Root Cause (Nguyên nhân gốc rễ): Nested if/else khiến logic name === "" bị "gộp" chung với !user.profile.name, dẫn đến nhầm lẫn giữa "không có tên" và "tên rỗng".

Fix (Sửa lỗi): Dùng guard clause để mỗi điều kiện độc lập. Tách rõ:

• Không có profile → "Anonymous"
• name falsy hoặc rỗng → "Anonymous"
• Còn lại → name

Prevention (Phòng ngừa):

• Code review: kiểm tra xem else có "xa" if tương ứng không.
• Tự hỏi: "Nếu điều kiện này đúng, tôi muốn làm gì?" → viết guard clause.

11. Design Exercise (Bài tập thiết kế giải pháp)

INFO

Ở depth L3, bài tập thiết kế tập trung vào quyết định đơn giản giữa các lựa chọn.

Context (Bối cảnh): Bạn review PR của đồng nghiệp. Họ viết:

function submitForm(formData) {
  let result = "";
  if (formData) {
    if (formData.email) {
      if (formData.email.includes("@")) {
        if (formData.password) {
          if (formData.password.length >= 8) {
            result = "Submitting...";
          } else {
            result = "Password too short";
          }
        } else {
          result = "Password required";
        }
      } else {
        result = "Invalid email";
      }
    } else {
      result = "Email required";
    }
  } else {
    result = "No data";
  }
  return result;
}

Question:

1. Có bao nhiêu cấp lồng nhau?
2. Refactor thành guard clauses. Mỗi guard trả về message gì?
3. Happy path cuối cùng là gì?

[Đáp án tham khảo]

1. 5 cấp lồng nhau (nếu tính cả formData).
2. Refactor:

   function submitForm(formData) {
     if (!formData) return "No data";
     if (!formData.email) return "Email required";
     if (!formData.email.includes("@")) return "Invalid email";
     if (!formData.password) return "Password required";
     if (formData.password.length < 8) return "Password too short";
   
     return "Submitting...";
   }

3. Happy path: return "Submitting..." ở cột trái, không bị lồng.

12. Production Scenario (Tình huống thực tế)

Bối cảnh: Bạn làm việc trên codebase legacy. Một hàm xử lý thanh toán dài 80 dòng, với 6 cấp if lồng nhau. Mỗi lần sửa bug, bạn phải cuộn màn hình để tìm xem else tương ứng với if nào.

Câu hỏi:

1. Tại sao nested if dễ gây bug khi maintain?
2. Nếu bạn refactor thành guard clauses, bạn cần đảm bảo điều gì trước tiên?
3. Khi nào bạn KHÔNG nên refactor (ví dụ: hàm đang có side effect cần cleanup)?

[Đáp án tham khảo]

1. Nested if khiến người đọc phải "nhớ" context bên ngoài. else xa if dễ ghép nhầm. Sửa một nhánh có thể ảnh hưởng nhánh khác.
2. Cần đảm bảo behavior giữ nguyên — viết test (hoặc manual verification) trước khi refactor.
3. Không refactor nếu hàm có resource cần cleanup (file, connection, lock) và đang dùng try/finally hoặc structured cleanup.

13. AI-assisted Exercise (Bài tập với AI)

Level B — Challenge (Thử thách)

1. Tự viết trước: Viết một đoạn giải thích ngắn (3–5 câu) về tại sao guard clause + early return tốt hơn nested if/else. Tập trung vào đọc hiểu và maintain.
2. Đưa cho AI review: Dùng prompt: "Review my explanation of guard clauses vs nested if/else. Is it accurate? What am I missing?"
3. So sánh: AI có nhắc đến "happy path" và "fail fast" không? AI có cảnh báo về trường hợp không nên dùng early return không?
4. Verify: Kiểm tra lại bằng tài liệu "Clean Code" của Robert C. Martin (chương về Functions) hoặc bài viết trên blog engineering uy tín.

Gợi ý

AI thường nói: "Guard clauses make code cleaner." Điều này đúng nhưng mơ hồ. Hãy kiểm tra xem AI có giải thích tại sao nó dễ đọc hơn (happy path phẳng, không cần nhớ context ngoài) hay chỉ nói "cleaner". AI cũng có thể bỏ sót cảnh báo về resource cleanup.

[Đáp án tham khảo]

• Bạn nghĩ: Guard clause đảo ngược điều kiện — thay vì "nếu đúng thì làm", ta nói "nếu sai thì thoát". Điều này đẩy logic chính ra cột trái, không bị thụt vào. Người đọc không cần nhớ 3–4 lớp if bên ngoài. Nhưng early return không phù hợp khi cần cleanup resource, vì có thể bỏ qua finally.

• AI trả lời: "Guard clauses reduce nesting and improve readability. They follow the fail-fast principle. Early returns make the happy path obvious." — Đúng ở bề mặt.

• So sánh: AI đúng về lợi ích, nhưng có thể không nhắc đến:

  • Tại sao nó dễ đọc: vì working memory của con người giới hạn (7±2 items), nested if tiêu tốn working memory.
  • Caveat về resource cleanup: AI thường không nhắc đến trường hợp early return gây leak.
  • Single Level of Abstraction: AI hiếm khi nhắc đến khái niệm này.

• Điểm AI nói sai hoặc quá mơ hồ:

  • "Cleaner" là subjective. AI không giải thích mechanism (happy path flat, no context tracking).
  • AI có thể không nhắc đến việc guard clause giúp mỗi điều kiện độc lập — sửa một guard không ảnh hưởng guard khác.

• Kết luận: Nếu bạn chỉ ra được rằng guard clause giảm cognitive load (không cần nhớ context ngoài) và giữ happy path ở một level — bạn đã hiểu sâu hơn AI. Điều này sẽ quay lại ở Stage 5 (Error handling patterns), Stage 8 (React component guard), và Stage 12 (Architecture — SLA).

14. Teach Back (Dạy lại)

Yêu cầu: Giải thích cho một đồng nghiệp Junior trong 2 phút:

"Tại sao tôi nên dùng guard clause thay vì viết if lồng nhau? Và khi nào tôi KHÔNG nên dùng early return?"

Dùng đúng terminology: guard clause, early return, happy path, pyramid of doom, fail fast.

Mô phỏng

• Bạn nói: if lồng nhau tạo ra "pyramid of doom" — code thụt vào nhiều cấp, bạn phải nhớ từng lớp điều kiện bên ngoài để hiểu logic chính. Guard clause đảo ngược: thay vì "nếu đúng thì làm", ta nói "nếu sai thì return". Kết quả là happy path nằm phẳng ở cột trái. Nhưng đừng dùng early return nếu bạn cần cleanup — ví dụ mở file rồi return giữa chừng mà quên đóng, sẽ leak resource. Trong trường hợp đó, try/finally hoặc structured pattern khác phù hợp hơn.

💡 Hãy tưởng tượng đọc code như đi qua một tòa nhà. Nested if là đi vào từng phòng nhỏ bên trong phòng — bạn dễ lạc. Guard clause là các cửa kiểm soát ở sảnh — nếu không đủ điều kiện, bị mời ra ngay. Còn lại, bạn tự do đi trong tòa nhà.

Gợi ý đánh giá bản thân

• Đồng nghiệp có hiểu tại sao "happy path phẳng" giúp đọc code dễ hơn không?
• Bạn có thể chỉ ra một đoạn code thực tế (trong dự án của bạn) và refactor nó không?
• Bạn có thể giải thích tại sao early return trong hàm có try/finally là risky không?

15. Assessment (Đánh giá)

Objective (Mục tiêu)	Hình thức đánh giá	Tiêu chí
Nhận diện pyramid of doom	Classification (Phân loại)	Tìm đúng ≥ 2/3 đoạn code lồng nhau
Refactor nested → guard	Implementation (Thực hành)	Code flat, behavior giữ nguyên
Giải thích lợi ích	Explain (Giải thích)	Dùng đúng terminology, nhắc đến happy path
Phân biệt khi không dùng	Decision (Quyết định)	Chọn đúng pattern cho từng scenario
Kết hợp short-circuit	Implementation (Thực hành)	Dùng &&/|| trong guard ngắn gọn

16. Exit Criteria (Tiêu chí qua bài)

• [ ] Có thể nhận diện "pyramid of doom" trong code thực tế.
• [ ] Có thể refactor ít nhất 2 hàm nested if/else thành flat guard clauses + early return.
• [ ] Có thể giải thích tại sao flat structure giảm cognitive load — dùng khái niệm "happy path".
• [ ] Có thể phân biệt khi nào early return phù hợp và khi nào cần tránh (resource cleanup).
• [ ] Có thể kết hợp short-circuit (&&, ||) với guard clauses để viết validation ngắn gọn.

17. Spiral Connection (Liên kết xoắn ốc)

Previous (Trước): Conditional Logic (0.4.2) → Short-circuit Evaluation (0.4.3)

Current (Hiện tại): Guard Clauses & Early Return — pattern viết code flat, fail fast, giữ happy path ở cột trái.

Next (Tiếp theo): Loops (0.4.5) → Error Handling (0.7.1–0.7.4) → React component conditional rendering (Stage 8) → Function design & Single Responsibility (Stage 1) → Architecture — Single Level of Abstraction (Stage 12)