During my freshman year of college I was recommended this book. Since then I have read the earlier chapters quite a bit, and struggled to get through the later chapters. This is probably because the earlier chapters contain principles that apply to any language or system, and the later ones focus on specific topics and technologies.
Looking back on this book, it appears pretty difficult for a student to read on their own, as it doesn't fully explain all concepts. In an educational setting, chapter 17 is the most useful and should probably be studied first. For a recent grad, a lot of these concepts are probably required these days, such as writing smaller functions, judiciously using comments, and appropriate naming.
I think there is still a better book out there with the same concepts, which could all be done with pseudo code
Opens with motivation to write "clean code". It creates an image of what a dysfunctional code base feels like, but not what it looks like. The chapter includes a series of descriptions of clean code by professional (and possibly well known) coders. Every other description is useless or hand wavey. The ones I appreciate are "Big" Dave Thomas, Ron Jefferies, and Ward Cunningham, who mention specific features of the code and use engineering words such as "minimal" over "crisp". I don't think "crisp" is a word appreciated by formal mathematicians, but the book does have a bent toward "art and craftsmanship". Not to say I don't think code can be beautiful and elicit emotion, but only in its own mathematically way. Make note of the 10:1 read/write ratio. Its useful, but is not linked back to any source.
I found this to be a useful chapter. It takes a lot of experience and practice to maximize the information gain of a single name. Take some time to think of the best name, but only through experience working with code bases will you learn what name is most useful to the team, not just for yourself.
The section "Have No Side Effects" does not explain what a side effect is, something a new coder should look up. The section "How Do You Write Functions Like This?" makes a great point on massaging code and going through it multiple times. If you do have the time, successive passes can make some truly readable code.
I probably would have chosen the word "Interfaces" to describe this chapter.
There are a few Java specific sections, and it feels like a very short design patterns section. There is also a subtle reference to "todays stories", which must be a agile (remember? It was in the title!) specific concept.
Better named, "Code writing process".
The section "No Duplication" takes a hard stance against duplication. This makes sense for small projects, but I would like to remind the viewer that duplication does happen. At some point, the human communcation and computational costs far outweigh re-writing a function. I am sure google has some duplicate code in a couple places. You could also imagine the task of taking code and removing duplication as a compression problem. From what we know of compression problems, there is usually a tradeoff between compression ratio and time spent compressing.
This section is a small "rules of thumb" section, which of course will handle 80% of the issues you find. Once you understand the "what" learning the "why" will really cement the knowedge.