Clean code basics — cheat sheet

General practice, no course slide source — written directly, same as 12-solid-principles.md. Mostly a collection of names for habits already implicit in earlier material (SRP, small service classes, avoiding one-off private methods) — useful to have the actual terminology ready.

Naming

• Names should reveal intent: daysSinceLastLogin beats d or data. Loop indices (i, j) and very short-lived locals are the accepted exception, not the rule.
• Avoid names that mislead about type or behavior (a List named accountGroup reads like a single account).
• Be consistent: pick one term per concept project-wide (fetch vs get vs retrieve for the same kind of operation causes constant re-checking).

Functions/methods

• Small, and doing one thing — the method-level version of Single Responsibility. If a method needs a "step 1 / step 2 / step 3" comment to explain itself, that's usually a sign it should be three methods.
• Few parameters — beyond 3-4, consider grouping related parameters into an object.
• Prefer command-query separation: a method either does something (returns void, has a side effect) or answers something (returns a value, no side effect) — not both. A method like boolean saveAndCheckIfValid() mixes the two and is harder to reason about and reuse.
• Prefer guard clauses / early returns over deep nesting:

  // instead of:
  if (user != null) {
      if (user.isActive()) {
          // do the thing
      }
  }
  // prefer:
  if (user == null || !user.isActive()) return;
  // do the thing

DRY, KISS, YAGNI

• DRY (Don't Repeat Yourself) — the same piece of logic/knowledge shouldn't be duplicated in multiple places; duplication means fixing a bug or a rule change requires remembering every copy.
• KISS (Keep It Simple) — prefer the straightforward solution over a clever one; cleverness costs the next reader (often future-you) time to decode.
• YAGNI (You Aren't Gonna Need It) — don't build configurability, abstraction, or generality for a requirement that doesn't exist yet. Matches the earlier course guidance against premature service-class splitting (01-data-and-service-classes.md) — added flexibility has a real complexity cost, so only pay it when the need is real.

Comments

• Prefer code that explains itself (good names, small functions) over a comment explaining what code does.
• A comment earns its place when it explains why — a non-obvious constraint, a workaround for a specific bug, a business rule that isn't visible in the code itself.
• Commented-out old code and TODOs left indefinitely tend to rot — worth flagging as a smell if seen in an interview code sample.

Magic numbers/strings

• An unexplained literal (if (status == 3), discount * 0.15) forces the reader to go find out what it means. A named constant (STATUS_SHIPPED, LOYALTY_DISCOUNT_RATE) documents it in place and gives you one spot to change it later.

The Boy Scout Rule

Leave the code a little cleaner than you found it — doesn't mean large unrelated refactors dropped into an unrelated change, just small, low-risk improvements (a better name, an extracted method) as you're already touching that area.

Interview framing

Often shows up as "what would you improve about this snippet" rather than a direct definition question — practice spotting: a god-method doing five things, magic numbers, a misleading name, or deep nesting that a guard clause would flatten.