Philosophy of Software Design — Chapters 14, 15 & 16
Philosophy of Software Design — Chapters 14, 15& 16
John K. Ousterhout
Choosing Names
Write The Comments First
Modifying Existing Code
Lesson duration is: 45 minItems in this lesson
Philosophy of Software Design — Chapters 14, 15& 16
John K. Ousterhout
Choosing Names
Write The Comments First
Modifying Existing Code
Design it Twice
Why Write Comments? The Four Excuses
Comments Should Describe Things that Aren’t Obvious from the Code
Recap: what do you remember from last time?
2
minute
00
second
Chapter 14: Choosing Names
Choosing good names is an underrated aspect of software design; they serve as documentation, reduce the need for other documentation, and help detect errors. Poor names increase complexity and cause bugs.
Do you remember a bug or time wasted caused by a bad name?
Codex searched for us
data playerData
Generic name hides that it represents the latest player state. Link
data pinEntryViewData
Vague; clarifying that it contains pin entry view information aids readability. Link
active isActive
Boolean variable not expressed as a predicate. Link
items pinAnswerPairs
Generic plural obscures that the map holds pin–answer tuples. Link
list graphQLErrorCodes
Non-descriptive placeholder for a list of known GraphQL error codes. Link
results match
Ambiguous name for regex execution result; match clarifies intent. Link
data tokenPayload
Generic name for HTTP JSON response; tokenPayload reveals the contents. Link
What did you think about the go example?
one letter vars
Chapter 15: Write The Comments First
The author asserts that the best time to write comments is at the very beginning of the development process, integrating them as a design tool. Delaying comments until after coding often results in them never being written or being of poor quality, as memories of design decisions fade, and it's seen as "drudge work"
After reading this, do you think you will try 'comments first?
Never!!!
I don't think so
Maybe, if situation ...
I will try it
Already started!
Can you think of a module that would not pass the "canary in the coal mine of complexity" if you would write the comments now?
Chapter 16: Modifying Existing Code
Software systems continuously evolve, so designs are never static. When modifying existing code (for bug fixes or new features), developers must stay strategic rather than adopting a tactical "quick fix" mindset.
Thoughts on this chapter?
How will you change your behaviour based on these three chapters?
2
minute
00
second
