A Philosophy of Software Design, 2nd Edition
  • 简体中文
  • English
  • 繁体中文
GitHub
  • 简体中文
  • English
  • 繁体中文
GitHub
  • Introduction
  • Preface
  • Chapter 1 Introduction
  • Chapter 2 The Nature of Complexity
  • Chapter 3 Working Code Isn’t Enough(Strategic vs. Tactical Programming)
  • Chapter 4 Modules Should Be Deep
  • Chapter 5 Information Hiding (and Leakage)
  • Chapter 6 General-Purpose Modules are Deeper
  • Chapter 7 Different Layer, Different Abstraction
  • Chapter 8 Pull Complexity Downwards
  • Chapter 9 Better Together Or Better Apart?
  • Chapter 10 Define Errors Out Of Existence
  • Chapter 11 Design it Twice
  • Chapter 12 Why Write Comments? The Four Excuses
  • Chapter 13 Comments Should Describe Things that Aren’t Obvious from the Code
  • Chapter 14 Choosing Names
  • Chapter 15 Write The Comments First
  • Chapter 16 Modifying Existing Code
  • Chapter 17 Consistency
  • Chapter 18 Code Should be Obvious
  • Chapter 19 Software Trends
  • Chapter 20 Designing for Performance
  • Chapter 21 Decide What Matters
  • Chapter 22 Conclusion
  • Summary

Chapter 18 Code Should be Obvious

Obscurity is one of the two main causes of complexity described in Section 2.3. Obscurity occurs when important information about a system is not obvious to new developers. The solution to the obscurity problem is to write code in a way that makes it obvious; this chapter discusses some of the factors that make code more or less obvious.

If code is obvious, it means that someone can read the code quickly, without much thought, and their first guesses about the behavior or meaning of the code will be correct. If code is obvious, a reader doesn’t need to spend much time or effort to gather all the information they need to work with the code. If code is not obvious, then a reader must expend a lot of time and energy to understand it. Not only does this reduce their efficiency, but it also increases the likelihood of misunderstanding and bugs. Obvious code needs fewer comments than nonobvious code.

“Obvious” is in the mind of the reader: it’s easier to notice that someone else’s code is nonobvious than to see problems with your own code. Thus, the best way to determine the obviousness of code is through code reviews. If someone reading your code says it’s not obvious, then it’s not obvious, no matter how clear it may seem to you. By trying to understand what made the code nonobvious, you will learn how to write better code in the future.

18.1 Things that make code more obvious

18.2 Things that make code less obvious

18.3 Conclusion

Another way of thinking about obviousness is in terms of information. If code is nonobvious, that usually means there is important information about the code that the reader does not have: in the RaftClient example, the reader might not know that the RaftClient constructor created new threads; in the Pair example, the reader might not know that result.getKey() returns the number of the current term.

To make code obvious, you must ensure that readers always have the information they need to understand it. You can do this in three ways. The best way is to reduce the amount of information that is needed, using design techniques such as abstraction and eliminating special cases. Second, you can take advantage of information that readers have already acquired in other contexts (for example, by following conventions and conforming to expectations) so readers don’t have to learn new information for your code. Third, you can present the important information to them in the code, using techniques such as good names and strategic comments.

Last Updated: 5/14/25, 1:24 AM
Prev
Chapter 17 Consistency
Next
Chapter 19 Software Trends