1 The aesthetics of code

1.1 Defining beautiful code

1.1.1 As developers, we can find common ground to define beauty in code

1.1.2 The understanding of beauty can evolve with the level of knowledge

1.1.3 The patterns of beautiful code

1.2 Why use Java to demonstrate beauty in code?

1.3 A simple example of beautiful code

1.3.1 The null horror maze

1.3.2 A classic scenario

1.3.3 Enter Java 8 to the rescue

1.4 From craftsmanship to artistry

1.5 Summary

2 Narrative code

2.1 Writing code as storytelling

2.2 The plot

2.3 Code typography

2.4 High-level storytelling

2.4.1 A long and boring story

2.4.2 Understanding the story

2.4.3 Simplifying the story

2.4.4 Levels of narrative: Action, scene, chapters, and table of contents

2.4.5 Choosing where to break the story

2.5 The characters

2.6 The ending

2.7 Summary

Overview

1 The aesthetics of code

This chapter presents programming as an artistic craft in which beauty matters because code is read by humans before it is run by machines. Beauty makes intent obvious, reduces cognitive load, and improves maintainability and onboarding. Through a simple transformation—from verbose, defensive null checks to a concise, expressive pipeline—the chapter shows how clarity emerges when the “billion‑dollar mistake” of null is handled explicitly. It argues that while tastes vary, developers share a common culture that can agree on broad principles, and that appreciation of beauty grows with knowledge as new language features become familiar.

Beauty in code is framed as intellectual harmony, echoing mathematics where elegant patterns reveal deeper order. The book introduces eight reinforcing dimensions—storytelling, simplicity, expressiveness, clarity of intent, purity, durability, sustainability, and creativity—none superior to the others, each strengthened by the rest. Overemphasizing one (such as purity) can harm readability unless balanced by simplicity and expressiveness. Together, readable “stories,” refined simplicity, expressive language features, data‑centered designs, functional discipline, resilient architectures, environmental awareness, and inventive problem solving produce elegant software.

Java is chosen as the vehicle due to its ubiquity, stability, and capacity to showcase both ugly and beautiful solutions, though the principles generalize to other languages. The chapter walks through refactoring nested calls and scattered null checks into an Optional‑based, functional flow (map, flatMap, or), encouraging returning Optionals instead of null, using null objects or explicit exceptions when appropriate, and avoiding Optional in fields or parameters. It notes AI’s usefulness for explanations, boilerplate, tests, and refactoring, while cautioning that it struggles to produce production‑ready or truly beautiful code without precise guidance. The chapter closes by extending craftsmanship into artistry: beyond clean, tested, maintainable code, beauty adds elegance and pride, inviting developers to pursue work that reflects both skill and passion.

Beautiful code: a rosette with 6 petals.

A product may have a discounted price, a base price, both, or none.

UML Class diagram showing a Product with nested pricing details.

Optional: it can hold a value or be empty, requiring you to handle both cases explicitly.

The map method for Optional.

Summary

Beautiful code isn't just aesthetic; it’s about writing higher-quality software.
Elegance in code leads to smoother onboarding for new developers, easier maintenance, longer-lasting code, and greater professional satisfaction.
Beautiful code can be understood through eight key dimensions: storytelling, simplicity, expressiveness, clarity of intent, purity, durability, sustainability, and creativity.
Null references, though a source of bugs in Java, can be handled more robustly and elegantly using modern features like Optional and functional patterns.

FAQ

What does “beautiful code” mean in this chapter, and why does it matter?

Beautiful code balances clarity, simplicity, expressiveness, and intention. It’s more than aesthetics: it improves readability, maintainability, onboarding, and long-term durability. Since code is read far more than it’s written, beauty becomes a practical necessity, not a luxury.

What are the eight dimensions of beauty in code introduced here?

- Storytelling - Simplicity - Expressiveness - Clarity of intent - Purity - Durability - Sustainability - Creativity These dimensions reinforce one another (modeled as a rosette rather than a hierarchy).

Why is the “null horror maze” considered ugly, and what principle does it violate?

It’s verbose, repetitive, and fragile, burying intent under defensive null checks. It violates the Law of Demeter by reaching deep into object graphs (e.g., product.pricingDetails().discountedPrice()), coupling code to internal structure and increasing brittleness.

How does Optional improve code compared to manual null checks?

Optional makes absence explicit and composable. With methods like ofNullable, map, flatMap, or, and ifPresent(OrElse), you can express “what” you want (business intent) without cluttering “how” with repeated null checks. The result is clearer, safer, and easier to maintain.

What’s the difference between map and flatMap on Optional, and when should I use or()?

- map: transforms the contained value and wraps the result in an Optional; skips work if empty. - flatMap: like map, but for functions that already return an Optional, avoiding nested Optionals. - or(): supplies an alternative Optional when the current one is empty (e.g., fall back from discounted to base price).

When should I return Optional, throw an exception, or use a default value?

Return Optional when absence is a normal, expected outcome. Throw an exception when absence is exceptional (e.g., a missing price that must be present). Default values can work, but only when they’re semantically safe; avoid misleading fallbacks like 0 for prices if it can mask errors.

What are common pitfalls and best practices for using Optional?

- Don’t use null to represent an Optional. - Avoid Optional in fields and parameters; it forces boilerplate on callers. Prefer null-object pattern for fields and regular parameters for inputs. - Don’t over-chain Optionals when a simple condition is clearer—clarity wins.

Why does the book use Java to demonstrate beauty in code?

Java’s wide adoption, strong backward compatibility, and evolving expressiveness (lambdas, streams, records, pattern matching) make it a practical vehicle. Java allows both beautiful and ugly code, making contrasts instructive. While examples are in Java, the principles are language-agnostic.

How does AI fit into writing beautiful code, according to the chapter?

AI is a helpful assistant for explanations, documentation, boilerplate, tests, refactoring, and debugging. But it often needs detailed guidance to produce elegant, durable solutions; “make it beautiful” isn’t enough. For complex, long-lived systems, human expertise remains essential.

How does “software craftsmanship” relate to “artistry” in this context?

Craftsmanship emphasizes well-crafted, clean, tested, maintainable code. Artistry adds the human dimension—striving for elegance, expressiveness, and simplicity that make you proud of the work. They’re complementary: beauty amplifies quality and deepens purpose.

1.1.1 As developers, we can find common ground to define beauty in code

1.1.2 The understanding of beauty can evolve with the level of knowledge

1.1.3 The patterns of beautiful code

1.3.1 The null horror maze

1.3.2 A classic scenario

1.3.3 Enter Java 8 to the rescue

2.4.1 A long and boring story

2.4.2 Understanding the story

2.4.3 Simplifying the story

2.4.4 Levels of narrative: Action, scene, chapters, and table of contents

2.4.5 Choosing where to break the story

3.1.1 Code complexity

3.1.2 Cognitive complexity

3.2.1 Prevent

3.2.2 Organize

3.2.3 Reduce

3.2.4 Hide

3.2.5 Investigate

3.2.6 Endure

5.1.1 The risk of mutable data

5.1.2 Understanding the burden of encapsulation

5.2.1 Beauty in record time

5.2.2 Practical uses for Java records

Beautiful code: a rosette with 6 petals.

A product may have a discounted price, a base price, both, or none.

UML Class diagram showing a Product with nested pricing details.

Optional: it can hold a value or be empty, requiring you to handle both cases explicitly.

The map method for Optional.

pro $24.99 per month

lite $19.99 per month

team

pro

team

pro

team