Skip to content

Make intentional design decisions

Every line of code embodies at least one design choice. Write code with deliberate intent rather than by accident or habit. Avoid just-in-case programming.

When you don’t know, follow default guidelines.

Even seemingly simple code involves multiple choices:

auto result = process(data);

This single line contains decisions about:

  • auto vs explicit type (explicitness vs brevity)
  • Value vs reference return (ownership and performance)
  • Return parameter vs out/in-out parameter
  • Function naming (expressing intent and understanding)
  • Error handling strategy (exceptions, error codes, or optional)

It is important to be aware that every detail communicates something to the reader. A junior developer might write a line of code without const, not yet having fully developed the habit of using const correctness, and without realizing how others interpret the code.

An experienced C++ developer will immediately notice if the keyword const is missing and wonder “How is the value going to be modified?”. When they don’t find any line of code that changes the value, they could waste time checking if they overlooked some important side-effect that does modify the variable.

Every day coding involves choices like:

  • Memory management: Stack vs heap allocation
  • Semantics: Value vs Reference Semantics
  • Const correctness: const vs mutable
  • Containers: std::vector vs std::array vs std::deque
  • Algorithms: Raw loop vs algorithm vs range-based for
  • Error handling: Exception vs error codes vs std::optional
  • Abstraction: Template vs inheritance, extract class/function vs inline code
  • Extension: Support extension of operations or extension of types (Expression Problem)

It requires years of experience to be able to always know what decision to make. Fortunately, in many situations we can default to generic guidelines such as the C++ Core Guidelines. It is generally better to follow standard conventions, than to do something unusual by accident.

Make your design decisions visible to other developers:

  • Use tests as executable documentation - Tests express intended behavior
  • Apply decisions consistently across the codebase
    • Justify and document any deviation from the standard
  • Code reviews help ensure intent is clear

Every design decision involves trade-offs. Being intentional means:

  • Understanding what you’re gaining and losing
  • Recognizing that context matters - the “best” choice depends on constraints, team, and domain
  • Deviating only from conventional practices (C++ Core Guidelines, idiomatic C++, team conventions, industry best practices) when you have justifiable reasons