DEV Community

Discussion on: In Defense of Clean Code: 100+ pieces of timeless advice from Uncle Bob

View post

Replies for: Thanks for the summary! Now, to balance things a bit, here's what I don't like about the book: It often put the responsibility of bad code on the...

Collapse
 
peerreynders profile image
peerreynders •

DRY is not about code duplication, it's about duplication of knowledge.

Yet another reference:

every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Aside: Development by Slogan

The code shouldn't have one responsibility, but enough responsibility to be coherent.

Ironically:

Gather together those things that change for the same reason, and separate those things that change for different reasons.

Perhaps at times he gets more caught up in his slogans than the essential messages.

I mean what's a "SetupTeardownIncluder"?

Kevlin Henney regularly likes to haul this one out for some of his talks.

I would recommend The Pragmatic Programmer or Refactoring (from Fowler) more than Clean code.

I tend to agree because they have already proven to be more timeless (and less context sensitive) because both of them have successfully moved to a 2nd edition after an already long period of relevance:

For anyone not familiar with Dave Thomas:

Fowler about Workflows of Refactoring. The 2nd edition uses JavaScript:

Choosing JavaScript was deeply ironic for me, as many readers may know, I'm not a fan of it. It has too many awkward edge cases and clunky idioms. ECMAScript 2015 (ES6) introduced a rather good class model, which makes many object-oriented refactorings much easier to express, but still has annoying holes that are built into the fabric of the language from its earliest days. But the compelling reason for choosing it over Java is that isn't wholly centered on classes. There are top-level functions, and use of first-class functions is common. This makes it much easier to show refactoring out of the context of classes.

… but as such it still uses a predominantly class-oriented style (which in my personal opinion isn't the sweet spot for JS — but this is about mainstream development in general, not JS specifically).