Expressive power is the ability to turn an idea into clear, concise code without twisting syntax or stretching logic to force a solution. It is not mere brevity: code is expressive when its intent is easy to grasp, its flow is natural, and its structure stays close to the problem being solved. section 1.1.4 section 5.0
Judge expressiveness by a combination of signals: low cognitive complexity, little incidental code, readability, closeness to the problem, and safety. Fewer lines help only when they preserve understanding; a compact construct that requires readers to reconstruct hidden steps is cryptic rather than expressive. section 5.1 section 5.3
Remove mechanics from a mapping
A traditional Java switch can bury a simple format-to-message mapping under a mutable variable, repeated assignments, break statements, casts, and a final return. It is also fragile: a missing break can silently overwrite the POCKET message. Prefer a construct that makes the cases and their outcomes direct, provided the team can readily read it. section 5.1.1 section 5.0
Listing 5.1 Traditional Java switch over book formats
public String getPromotionalMessage(Book book)
throws UnsupportedBookFormatException {
String message;
switch (book.getFormat()) {
case DIGITAL:
message = ((DigitalBook) book).getDownloadLink();
break;
case POCKET:
message = "Same book, smaller format!";
case HARDCOVER:
message = "Old-fashioned book…";
break;
default:
throw new UnsupportedBookFormatException(book.getFormat());
}
return message;
}
This switch shows how control-flow plumbing and fall-through risk can obscure an otherwise direct mapping. section 5.1.1
Conciseness has a boundary. A method reference may hide parameters; a lambda can expose them; a for-each loop makes iteration and values fully visible. Likewise, dense Kotlin scope-function chains can compress several transformations until the code’s story becomes hard to follow. Choose the least complicated form that remains clear to its intended readers. section 5.2 section 5.2
Use expressive features when they improve the code’s story:
- Prefer idioms that improve readability, safety, or closeness to the domain, such as pattern matching, switch expressions, records, data classes, sealed types, pipelines, or named constructors. section 5.2
- Favor widely understood constructs over clever or advanced shorthand when familiarity would otherwise become a reading cost. section 5.2
- Balance expressiveness with simplicity and narrative code rather than maximizing brevity in isolation. section 1.1 section 5.3
