
核心要点
- Code is read far more often than it is written, so write for the reader
- Names should reveal intent so clearly that comments become almost unnecessary
- Functions should be small and do exactly one thing at one level of abstraction
- A comment is usually a confession that the code could not explain itself
- Leave every file a little cleaner than you found it, one small change at a time
本篇内容
- Code is written for people
Picture a developer opening a file written two years ago by a colleague who has since left. Every variable is called data or temp, one function runs for 300 lines, and nobody dares to touch it.
- Names carry the meaning
The cheapest improvement you can make is a better name. A variable named d tells you nothing; a variable named daysSinceLastLogin tells you everything, and it removes the need for a comment.
- Small functions that do one thing
Martin's rule for functions is simple to state and hard to follow: they should be small, and then smaller than that. A function should do one thing, do it well, and do only that.
- Comments are not a fix
Many programmers are taught that good code is heavily commented. Martin pushes back.
- Tests make cleaning safe
Why do teams leave ugly code alone? Fear.
- Put it to work
This week, pick the file you dread opening and rename three variables so their purpose is obvious without a comment. Find one long function and split out a single well-named piece, keeping behaviour identical, and run the tests before and after.
六种学习方式
为本书专门编写了可视化、思维导图、练习、场景、挑战和复习模式。
语音朗读
聆听此内容,由 Michael 或 Bella 朗读。
测验与抽认卡
测试你的阅读成果,并通过间隔重复巩固记忆。
Bits AI
它可以根据你正在看的书籍、章节或测验题来回答。





