📐 SOLID & Clean Code

Clean Code

Naming, function size, avoiding primitive obsession and magic strings.

Clean Code overlaps with SOLID but is more about day-to-day readability. Points that read as senior-level rather than textbook-recited:

Magic strings/primitive obsession: customerType == "Regular" (as in the email's example) is
a smell twice over — a typo compiles fine and fails silently at runtime, and there's no
compiler-enforced list of valid values. An enum CustomerType { Regular, Premium } (or a proper
value object) fixes both.
Function size / one level of abstraction per function: a function should read like a
well-named paragraph, not mix "what" and "how" at different zoom levels.
Command-Query Separation: a method either does something (command, returns void) or answers
something (query, returns a value) — not both, to avoid surprising side effects from something
that looks like a getter.
Guard clauses over nested conditionals: return/throw early on invalid input instead of wrapping
the "real" logic three ifs deep.

Flashcards (3)

What are the two concrete problems with using a raw string like "Regular" to represent customer type?

tap to reveal answer

No compile-time safety (a typo like "Regula" compiles and just silently falls through to the default case), and no single discoverable source of truth for the valid values — an enum or value object fixes both.

What is Command-Query Separation?

tap to reveal answer

A method should either be a command that performs an action/side effect (typically void) or a query that returns data with no observable side effect — never both, so calling something that reads like a getter never surprises you with a mutation.

What's a 'guard clause' and what does it replace?

tap to reveal answer

An early return/throw for invalid input or an edge case at the top of a method, replacing deeply nested if/else — keeps the main logic at a single indentation level instead of buried inside conditionals.