fundamentals-gate

name	fundamentals-gate
description	Verify code quality standards are met - naming, structure, DRY principles. Issues result in SUGGESTIONS for improvement.

Gate 5: Fundamentals Review

"Good code is not just code that works. It's code that others can work with."

Purpose

This gate checks general code quality against engineering standards. Issues are SUGGESTIONS, not blockers — they're polish, not problems.

Gate Status

• PASS — Code quality is solid
• SUGGESTIONS — Minor improvements recommended

---

Gate Questions

Question 1: Naming Clarity

"Would a new developer understand what [variable/function] does from its name alone?"

Looking for:

• Descriptive, intention-revealing names
• No abbreviations or single letters
• Boolean prefixes (is, has, can)
• Function verbs (get, set, handle)

Question 2: Function Focus

"Can you describe what this function does in one sentence without using 'and'?"

Looking for:

• Single responsibility
• Reasonable size (under 30 lines)
• Clear input/output relationship
• No hidden side effects

Question 3: Code Reuse

"I see this pattern in a few places. Is it intentional duplication or should it be extracted?"

Looking for:

• Awareness of duplication
• Appropriate abstraction (rule of three)
• Not over-engineering for one-time use

---

Fundamentals Checklist

Naming

• Variables are descriptive (no temp, data, x)
• Booleans prefixed with is, has, can, should
• Functions start with verbs
• No unnecessary abbreviations
• Consistent naming patterns

Functions

• Single responsibility
• Under 30 lines (generally)
• Fewer than 4 parameters
• Early returns instead of deep nesting
• No magic numbers (use named constants)

Structure

• Related code grouped together
• Appropriate file organization
• Clear separation of concerns
• Consistent formatting

Comments

• Explain WHY, not WHAT
• No commented-out code (delete it)
• No obvious comments (// increment counter)
• Complex logic documented

---

Response Templates

If PASS

✅ FUNDAMENTALS GATE: PASSED

Code quality is solid:
- Naming is clear and consistent
- Functions are focused
- Good structure overall

All gates passed! Let's move to code review...

If SUGGESTIONS

💡 FUNDAMENTALS GATE: SUGGESTIONS

A few polish items for consideration:

**Suggestion 1: [Naming]**
`const d = new Date()` → `const createdAt = new Date()`
Why: Descriptive names help future readers

**Suggestion 2: [Function size]**
`processOrder()` is 80 lines. Consider splitting into:
- `validateOrder()`
- `calculateTotal()`
- `saveOrder()`

**Suggestion 3: [Magic number]**
`if (status === 2)` → `if (status === STATUS.ACTIVE)`
Why: Named constants are self-documenting

These are suggestions, not blockers. The code works — this is about polish.
Proceed to code review? Or address these first?

---

Common Issues to Check

1. Unclear Naming

❌ const d = new Date();
   const temp = getUser();
   const flag = true;

✅ const createdAt = new Date();
   const currentUser = getUser();
   const isAuthenticated = true;

2. Magic Numbers

❌ if (status === 2) { ... }
   setTimeout(fn, 86400000);

✅ const STATUS = { ACTIVE: 2, INACTIVE: 1 };
   if (status === STATUS.ACTIVE) { ... }

   const ONE_DAY_MS = 24 * 60 * 60 * 1000;
   setTimeout(fn, ONE_DAY_MS);

3. Deep Nesting

❌ function check(user) {
     if (user) {
       if (user.active) {
         if (user.role === 'admin') {
           return true;
         }
       }
     }
     return false;
   }

✅ function check(user) {
     if (!user) return false;
     if (!user.active) return false;
     if (user.role !== 'admin') return false;
     return true;
   }

4. God Functions

❌ function processOrder(order) {
     // 100+ lines of validation, calculation, saving, emailing...
   }

✅ function processOrder(order) {
     validateOrder(order);
     const total = calculateTotal(order);
     await saveOrder(order, total);
     await sendConfirmation(order);
   }

5. Meaningless Comments

❌ // Increment counter
   counter++;

   // Get user
   const user = getUser();

✅ // Rate limit: max 100 requests per minute per user
   if (requestCount >= 100) {
     throw new RateLimitError();
   }

---

Socratic Fundamentals Questions

Instead of pointing out fixes, ask:

1. "What does d stand for? Would a new developer know?"
2. "What does the number 2 mean in this context?"
3. "Can you describe this function without saying 'and'?"
4. "I see this pattern three times — is that intentional?"
5. "Would you understand this comment in 6 months?"

---

Standards Reference

See detailed patterns in:

• /standards/global/naming-conventions.md
• /standards/global/error-handling.md
• /standards/frontend/component-architecture.md

---

Naming Quick Reference

Type	Pattern	Example
Variable	camelCase, descriptive	userEmail, isLoading
Boolean	is/has/can/should prefix	isActive, hasPermission
Function	verb + noun	getUser(), handleSubmit()
Constant	UPPER_SNAKE_CASE	MAX_RETRIES, API_URL
Class	PascalCase	UserService, ApiClient

---

When to Skip Suggestions

Not every suggestion needs addressing:

• Prototype code — Polish can wait
• Time pressure — Ship working code, polish later
• Minimal impact — If it's just style preference
• Existing patterns — Match codebase conventions even if imperfect

Fundamentals are about growth, not perfection. Note suggestions for learning, but don't block shipping.