Clean Code vs. A Philosophy Of Software Design • Hacker News Board

Re: Clean Code vs. A Philosophy Of Software Design

#121

Post by abhis3798 » Tue, Feb 25, 2025, 8:47 AM UTC

narnarpapadaddy wrote: post #47

marcusbuffett wrote: post #11

I strongly recommend "A Philosophy of Software Design". It basically boils down to measuring the quality of an abstraction by the ratio of the complexity it contains vs the complexity of the interface. Or at least, that's the rule of thumb I came away with, and it's incredible how far that heuristic takes you. I'm constantly thinking about my software design in these terms now, and it's hugely helpful. I didn't feel…

Implicitly, IIRC, the optimal ratio is 5-20:1. Your interface must cover 5-20 cases for it have value. Any fewer, the additional abstraction is unneeded complexity. Any more, and your abstraction is likely too broad to be useful/understandable. The example he gives specifically was considering the number of subclasses in a hierarchy. It’s like a secret unlock code for domain modeling. Or deciding how long functions s…

This is a good rule of thumb, but what would be a good response to have interfaces because, "what if a new scenario comes up in the future"?

Re: Clean Code vs. A Philosophy Of Software Design

#122

Post by coopykins » Tue, Feb 25, 2025, 8:55 AM UTC

As someone who's recently started to read a philosophy of software design, I have to say that a lot of the points the author makes are things that I've come to learn with experience, which feels pretty good. As opposed to clean code, which I read when I was starting, and although at that time it felt good to have some guidelines—I still think having some guidelines is better than having nothing at all.

I think you grow out of that advice very soon, because it's not very practical, it feels out of touch. The result is not code that is easier to read, quite the contrary. I think the Java world has been influenced for worse by him.

But I don't have anything against him, as other comments say, the problem is dogmatism and trying to follow these authors blindly instead of thinking about it.

Re: Clean Code vs. A Philosophy Of Software Design

#123

Post by lmm » Tue, Feb 25, 2025, 8:59 AM UTC

abhis3798 wrote: post #121

narnarpapadaddy wrote: post #47

Earlier quoted context omitted.

Implicitly, IIRC, the optimal ratio is 5-20:1. Your interface must cover 5-20 cases for it have value. Any fewer, the additional abstraction is unneeded complexity. Any more, and your abstraction is likely too broad to be useful/understandable. The example he gives specifically was considering the number of subclasses in a hierarchy. It’s like a secret unlock code for domain modeling. Or deciding how long functions s…

This is a good rule of thumb, but what would be a good response to have interfaces because, "what if a new scenario comes up in the future"?

"We'll extract interfaces as and when we need them - and when we know what the requirements are we'll be more able to design interfaces that fit them. Extracting them now is premature, unless we really don't have any other feature work to be doing?"

Re: Clean Code vs. A Philosophy Of Software Design

#124

Post by j_san » Tue, Feb 25, 2025, 9:00 AM UTC

imjonse wrote: post #74

I 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…

Biased against the approach of your former coworker and thus the "Clean Code" way? I assume it did not work out well, because you needed to move fast to build an MVP before trying to do it right?

Re: Clean Code vs. A Philosophy Of Software Design

#125

Post by wg0 » Tue, Feb 25, 2025, 9:03 AM UTC

The arguments from staunch clean code zealots have wasted so much time on PRs that I have lost count. Hours and hours and sometimes weeks - PRs having ideological discussions on something that neither the underlying machine cares nor the end user.

Multiply that across the industry and that probably easily reaches in hundreds of millions of dollars productivity wasted.

Ps: Not advocating cowboy coding or spaghetti code either.

Re: Clean Code vs. A Philosophy Of Software Design

#126

Post by Copenjin » Tue, Feb 25, 2025, 9:04 AM UTC

You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them.

Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a software engineer like many other prominent authors at the beginning of the agile era. The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.

Horrible recommendations that produced a lot of code that is a pain to work on with the abundant amount of indirection it has. Really painful guys.

Re: Clean Code vs. A Philosophy Of Software Design

#127

Post by Copenjin » Tue, Feb 25, 2025, 9:06 AM UTC

abhis3798 wrote: post #121

narnarpapadaddy wrote: post #47

Earlier quoted context omitted.

Implicitly, IIRC, the optimal ratio is 5-20:1. Your interface must cover 5-20 cases for it have value. Any fewer, the additional abstraction is unneeded complexity. Any more, and your abstraction is likely too broad to be useful/understandable. The example he gives specifically was considering the number of subclasses in a hierarchy. It’s like a secret unlock code for domain modeling. Or deciding how long functions s…

This is a good rule of thumb, but what would be a good response to have interfaces because, "what if a new scenario comes up in the future"?

The scenario NEVER comes up in the future as it was originally expected. You'll end up having to remove and refactor a lot of code. Abstractions are useful only used sparingly and when they don't account for handling something that doesn't even exist yet.

Re: Clean Code vs. A Philosophy Of Software Design

#128

Post by lmm » Tue, Feb 25, 2025, 9:07 AM UTC

getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

Yes, I've worked on a couple of codebases like that. It's glorious, you break everything down little by little and every step makes sense and can be tested individually. Best jobs I've had.

Re: Clean Code vs. A Philosophy Of Software Design

#129

Post by Copenjin » Tue, Feb 25, 2025, 9:08 AM UTC

WalterBright wrote: post #40

getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

Too often I see functions that are shells that reshuffle the arguments and pass them to another function, which also reshuffles the arguments and forwards them to another, and on and on. One was 11 layers deep.

And a lot of people doesn't understand how dangerous shuffling parameters is, especially in languages that do not have named parameters...

Re: Clean Code vs. A Philosophy Of Software Design

#130

Post by __loam » Tue, Feb 25, 2025, 9:10 AM UTC

Copenjin wrote: post #126

You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them. Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a so…

A Philosophy of Software Design on the other hand is concise, excellent, and based on decades of teaching experience.