It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…
For many C#, Java and C++ engineers Uncle Bob is their savior and GoF are the apostles. Everything should follow SOLID and clean principles and be implemented using design patterns.
Clean Code vs. A Philosophy Of Software Design
381–390 of 554 posts
Re: Clean Code vs. A Philosophy Of Software Design
#382I've enjoyed both books but Uncle Bob is something you grow out of. He was a bit of a cult figure at the time. Trying to actually follow the guidelines in Clean Code taught me a lot about "over-decomposition" and, ultimately, how not to write code. It reminds me it's possible to take aesthetics so far the results become ugly. Fussing over a proliferation of small functions that do only one thing is a kind of madness.…
it has been years since I read the book, but I'm surprised that there's so much hatred for it here. From memory it seemed like fairly harmless things like give things good names, try to make the code readable, dont comment what the code does but why, use consistent formatting, avoid duplication. Other than people going overboard with empty classes and inheritance Ive not really seen a problem of people breaking down…
Re: Clean Code vs. A Philosophy Of Software Design
#383Earlier quoted context omitted.
This is the silliest thing I've ever heard
Probably because you think you're smart AND you write excessively clean code and are excessively anal about it. Whether you actually are smart is a different story.
Re: Clean Code vs. A Philosophy Of Software Design
#384Re: Clean Code vs. A Philosophy Of Software Design
#385Earlier quoted context omitted.
Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…
When you're writing it you have the help of the compiler and various other tools, plus you have the model of what the code is doing fully-formed in your head, and you have the recent memory of various other approaches you took and how and why they failed. When you're reading it you have none of those things. So, code is harder to read than it is to write. So if you write code that uses your full intellect to write it…
They are likely writing code with a fraction of their intellect and that code is still too complicated for normal people to comprehend.
Re: Clean Code vs. A Philosophy Of Software Design
#386Earlier quoted context omitted.
Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…
I've been trying for years to track down a quote I lost, and it sounds like something you might know, because I think it would have resonated with you. It was from Charles Simonyi, talking about how as he got older, his prodigious ability to juggle large amounts of information in his head declined, and as a result, he started writing better code. Do you know it? Also, I half agree with your point, but I see it happen…
Re: Clean Code vs. A Philosophy Of Software Design
#387It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…
I cringe thinking about PR comments I left early in my career. "akshually this should try to follow more SOLID principles" But, coming from a formal engineering background, I thought this is what it meant to be a professional software engineer. Little did I know these "principles" were just the musings of a consultant lol. Turns out most folks have good intentions and want a standardized way to write code, but for so…
I wonder if that's because in a lot of cases (depending on the domain) the space of possible valid/working solutions is near infinite, and if you don't have hard requirements that are backed up by measurements you're free to concieve of any valid system structure and justify it as 'better' without that ever being something that can be observed and measured.
Re: Clean Code vs. A Philosophy Of Software Design
#388I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…
Let's not forget that Uncle Bob, by the time of writing "Clean Code" had 4 decades coding experience.
Re: Clean Code vs. A Philosophy Of Software Design
#389Re: Clean Code vs. A Philosophy Of Software Design
#390Earlier quoted context omitted.
> It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. IMO, this is one of the key differences between the two books. CC has a vibe of hard and fast opinion-based rules that you must obey, whereas APoSD feels more like empirically-derived principles or guidelines.
APoSD is written by a highly respected computer scientist with a tremendous list of technical achievements and also a strong teaching history as a professor, while CC was written by someone whose resume is primarily related to writing about software, not writing software.