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

Re: Clean Code vs. A Philosophy Of Software Design

#221

Post by NeutralForest » Tue, Feb 25, 2025, 2:10 PM UTC

ninetyninenine wrote: post #205

ilitirit wrote: post #145

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…

Well I mean they wrote books about it and one guy had the audacity to call his opinion a “philosophy” even though it’s just an arbitrary opinion. Most of software is about assigning big words and over complicated nomenclature to concepts and these things masquerade as things with deeper meaning when in reality it’s just some made up opinion. Software design is an art. It is not engineering and it is not science. That…

But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software.

Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies.

If we don't do that then it's just vibes right? Where's the engineering part?

Re: Clean Code vs. A Philosophy Of Software Design

#222

Post by bob1029 » Tue, Feb 25, 2025, 2:11 PM UTC

I'm currently dealing with one of those codebases representative of the consequences of blindly following "Clean Code", et. al.

My experience has taught me that you never want to be the first person to recommend a rewrite. Since I am a mere contractor on this one, I am strongly inclined to let it unwind on its own. There seems to be a lot of ego embedded in those pointless data access layer wrappers. I'd hate to get on someone's bad side right now. The market is quite rarified.

Re: Clean Code vs. A Philosophy Of Software Design

#223

Post by narnarpapadaddy » Tue, Feb 25, 2025, 2:15 PM UTC

kragen wrote: post #170

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…

Maybe some examples would clarify your intent, because all the candidate interpretations I can think of are absurd. The sin() function in the C standard library covers 2⁶⁴ cases, because it takes one argument which is, on most platforms, 64 bits. Are you suggesting that it should be separated into 2⁶⁰ separate functions? If you're saying you should pass in boolean and enum parameters to tell a subroutine or class whi…

Think of it more like a “complexity distribution.”

Rarely, a function with a single line or an interface with a single element or a class hierarchy with a single parent and child is useful. Mostly, that abstraction is overhead.

Often, a function with 5-20 lines or an interface 5-20 members or a class hierarchy with 5-20 children is a useful abstraction. That’s the sweet spot between too broad (function “doStuff”) and too narrow (function “callMomOnTheLandLine”).

Sometimes, any of the above with the >20:1 complexity ratio are useful.

It’s not a hard and fast rule. If your complexity ratio falls outside that range, think twice about your abstraction.

Re: Clean Code vs. A Philosophy Of Software Design

#224

Post by ahoka » Tue, Feb 25, 2025, 2:18 PM UTC

rester324 wrote: post #21

frozenlettuce wrote: post #8

Earlier quoted context omitted.

I don't know why people take UB seriously. He never provided proof of any work experience - he claims to have worked for just a single company that... never shipped any code into production. Even his code examples on GitHub are just snippets, not even a to-do app (well, I think that his style of "just one thing per function" works as a self-fulfilling prophecy). Maybe people like him are the reason why we have to do…

Uncle Bob is one of the core contributors to Fitnesse, which had moderate success in the Java popularity era back in the day. Also, you do understand that people worked as software engineers even before Github became popular, or open sourcing to begin with, do you? So if someone is 60+ year old, chances are that most of his work has never been open sourced, and his work was targeting use cases, platforms, services wh…

Do you mean commits to the project like this crap: https://github.com/unclebob/fitnesse/commit/d6034080a04c740c...

This level of pointless obfuscation would not survive a code review at any sane dev team.

Re: Clean Code vs. A Philosophy Of Software Design

#225

Post by ninetyninenine » Tue, Feb 25, 2025, 2:19 PM 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. This works but only if the functions are pure and using pure function composition.

Uncle bob doesn’t mention this.

   createspecialString(y) =
       Capitalizefirstletter .
       MakealllowerCase .
       AddNumberSuffix .
       removeLetterA .
       removeLetterB .
       ConcatwithWord(x)

   CapitalizeFirstLetter(a) = a[0].upper() + a[1:]
   MakeAllLowercase(a) = map(a, (t) => t.lower())
   Addnumbersuffix(a) a + 3.toString()
   RemoveLetterA(t) = filter(t, (s) => s.lower() == “a”)
   RemoveLetterB(t) = filter(t, (s) => s.lower() == “b”)
   ConcatenateWithWord(x) = (y) => y + x

There see? It’s mostly doable in pure functional composition where the dot represents function composition. I program like this all the time. No way anyone can pull this off while mutating state and instantiating objects.

   F . P = (x) => F(P(x))

Forgive some inconsistent formatting and naming im typing this on my phone.

People who complain about this style tend to be unfamiliar with it. If you had knowledge about procedural coding styles and a function composition approach like this then usually this style is easier as the high level function literally reads like English. You don’t need to even look at the definitions you already know what this complicated string formatting function does.

No comments needed. And neither author tells you about this super modular approach. They don’t mention the critical thing in that this style requires functions to be pure.

Thus to get most of your code following this extremely modular and readable approach… much of your code must be minimizing IO and state changes and segregating it away as much as possible.

The Haskell type system, the IO monad is pushing programmers in this direction.

Again neither author talks about this.

Re: Clean Code vs. A Philosophy Of Software Design

#226

Post by narnarpapadaddy » Tue, Feb 25, 2025, 2:21 PM UTC

narnarpapadaddy wrote: post #223

kragen wrote: post #170

Earlier quoted context omitted.

Maybe some examples would clarify your intent, because all the candidate interpretations I can think of are absurd. The sin() function in the C standard library covers 2⁶⁴ cases, because it takes one argument which is, on most platforms, 64 bits. Are you suggesting that it should be separated into 2⁶⁰ separate functions? If you're saying you should pass in boolean and enum parameters to tell a subroutine or class whi…

Think of it more like a “complexity distribution.” Rarely, a function with a single line or an interface with a single element or a class hierarchy with a single parent and child is useful. Mostly, that abstraction is overhead. Often, a function with 5-20 lines or an interface 5-20 members or a class hierarchy with 5-20 children is a useful abstraction. That’s the sweet spot between too broad (function “doStuff”) and…

And with respect to function behavior, I’d view it through the lens of cyclomatic complexity.

Do I need 5-20 non-trivial test cases to cover the range of inputs this function accepts?

If yes, function is probably about the right level of behavioral complexity to add value and not overhead.

If I need only 1 test or if I need 200 tests it’s probably doing too much or too little.

Re: Clean Code vs. A Philosophy Of Software Design

#227

Post by bluGill » Tue, Feb 25, 2025, 2:22 PM UTC

dgb23 wrote: post #201

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…

Clean code, design patterns etc. were also picked up by teachers, professors and course instructors. I think these paradigms and patterns often operate on the wrong layer of abstraction, while mostly ignoring the things that matter the most, like efficiency, error handling and debugging. But getting good at these things requires a lot more blood, sweat and tears, so there's no easily teachable recipe for that.

Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already efficient).

Of course error handling and debugging are part of maintenance. However there is a lot more than those two that need to be considered as well.

There is reason to hate Clean Code, but the worst adherents to the rules are still producing far better code than some of the impossible stuff that happened before. "Goto considered harmful" is one of the early steps in fixing all the bad things programmers used to do (and some still do), but you can follow the "rules" of goto considered harmful and still produce really bad code so we need more.

Re: Clean Code vs. A Philosophy Of Software Design

#228

Post by pclmulqdq » Tue, Feb 25, 2025, 2:26 PM UTC

Lyngbakr wrote: post #180

ilitirit wrote: post #145

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…

> 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.

Re: Clean Code vs. A Philosophy Of Software Design

#229

Post by ninetyninenine » Tue, Feb 25, 2025, 2:27 PM UTC

holoduke wrote: post #217

ninetyninenine wrote: post #211

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

Reality is that you have to work with different levels of intelligence. Your stack must be understandable also for the "common" programmer. Otherwise goodluck finding people.

True. But what I said is still true. The tendency exists.

Smart people don’t often know how smart they are and don’t realize how unreadable their code is until code review time and the stupid person points out what the smart person considered “obvious”

Re: Clean Code vs. A Philosophy Of Software Design

#230

Post by pclmulqdq » Tue, Feb 25, 2025, 2:29 PM UTC

k__ wrote: post #143

jacobsenscott wrote: post #113

I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm. Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesse…

If you don't nest that much, big functions aren't so bad. You can just scroll down and see what happens in a linear fashion.

This is the Linux kernel approach, and is a big part of why the kernel uses 8-space tabs. It's generally very effective for understanding what is happening. I'm happy with a 200-line straight-line-with-error-handling function, while a monstrosity of 10 20-line functions that all do if-else is quite a bit harder to read. The latter is "clean code."