3 ms·
Wow this is quite a takedown. For many years I was feeling like I let myself down by not reading the book Clean Code. I now feel like, by accident, I did exactl
by avg_dev 4y ago
Wow this is quite a takedown. For many years I was feeling like I let myself down by not reading the book Clean Code. I now feel like, by accident, I did exactly the right thing. That sample code he quoted is near unreadable to me. I also did enjoy A Philosophy of Software Design; the main thing I took away from it was to avoid unneeded complexity because you want to be able to “spend” your complexity budget for doing actual work.
- DotaFan 4y agoBlog is addressing small segment of a book, you might still be missing a good learning. Maybe you can scrim some chapters here: https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-of-timeless-advice-from-uncle-bob-5flk https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-...
- rgoulter 4y agoI generally liked APoSD. I liked its notion of symptoms of complex code. I liked its framing of complexity as related to dependencies involved in calling some function. -- If a function has more parameters than it really needs (too many dependencies), or a function has fewer parameters than it actually needs, then it's more complicated to work with than it needs to be (its actual dependencies are obscure). -- I liked its emphasis on "interface" is "what you need to know to use the code", as opposed to implementation details. I liked the suggestion of "writing documentation before the implementation" as a way of coming up with a clean interface; although I found it bizarre that this logic didn't carry across to "write some tests before the implementation".
- crucialfelix 4y agoIf you read the book, understand the principals and then disagree with a few of them, you will have learned more than if you never read it at all.