Hacker News Reader

Comment by pkolaczk | Hacker News Reader

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise.

Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean

The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.

IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed.

And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.

View on HN

I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?"

Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated.

That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.

that last paragraph is an excellent description of the problem!

Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.

Hm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...

I'd say false dilemma fallacy.

so ... sounds like you agree?

What is the alternative? Bad code?

It's exactly same as arguing you should not educate your workers. Cause they might leave. So you get only the least knowledgeable ones.

It's really not.

Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way".

So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.

That's not inconsistent with "good code will get rewritten until it's not good code." Good code that you need to change is code that can degrade as a result of that change.

Nothing to do with "just changing code because they feel like it".

The good code will be changed after it has ceased to be good code too. And bad code can become good code in the process of changing it.

There is nothing that makes good code more or less likely to change than bad code.

>good code is easy to change so it will easily get rewritten until it's not easy to change anymore

Sounds like the 'bad currency drives good currency out of circulation' problem. Bad code drives good code out, because good code is easy to understand and change.

exactly

Without concerted effort, any easy-to-change code naturally will be replaced by hard-to-change code.

> Bad code drives good code out, because good code is easy to understand and change.

I call this the Peter Principle of Programming:

"Code increases in complication to the first level where it is too complicated to understand. It then hovers around this level of complexity as developers fear to touch it, pecking away here and there to add needed features."

http://h2.jaguarpaw.co.uk/posts/peter-principle/

Very cool point.

I will highlight though that I have worked with people that choose the path of least resistance regardless of complexity of the code that would need to be changed. It's as if they refuse to read code.

This is why I think the most powerful abstraction for framework with extension points is c++ template meta programming. Wait! Hear me out!

Template meta programming is an entirely separate, incredibly complex, programming language distinct from c++. The only people I have ever seen use it in production are exceptionally skilled programmers. Everyone else flees and cowers. If they try to change it it will not compile. So why is this good? Because it only allows the framework to be extended in the ways intended by the original designer. Anyone wanting to update this unholy beast will be a master programmer who’s investing significant effort. That implies the updates will be good.

Good code is easy to change. Great code is near impossible to change, but easy to extend.

The ITK experience

you just sent shivers down my spine

Shivers of excitement surely

What happens when you have new requirements that weren't envisioned by the original designers, who are no longer there? How do you unravel the design to the point where you can create a new one?

With great effort. That’s kind of my point though. It’s when you are changing the design from the originally understood “these are the ways to extend and add”, to a new paradigm, that you should be expending great effort.

In such a code base, it quickly becomes understood that if changes are required to “framework Doom” in order to achieve a new feature, the time budget will need to be large. It’s built in tech-debt prevention.

> (...) because it was not written in the modern way or it was not very generic or whatever.

Premature generalization is a well known problem and a never-ending source of complexity. I lost count of the times I had to push back on PRs of clueless developers who felt the need to generalize one-liners that pop up twice in the whole project, and for that their proposal was to add a strategy pattern, ultimate replacing two expressions with three classes.

> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility.

https://nigeltao.github.io/blog/2021/json-with-commas-commen...

Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well).

I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises.

IMHO clean code also is more focused on code implementing "business logic" than "systems programming" for example (probably a bit tricky to actually define what the difference is between these too).

This begs the question: what do you recommend instead?

Programming practice

Code complete, Steve McConnell

Not the OP but HTDPv2 is a solid recommendation here

I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym.

For those wondering, "How to Design Programs"

Yeah fair comment. I guess i’ve fallen into that familiarity trap.

I also enjoyed the Hitchhiker's Tips for Deeper Pockets (v2).

"Code Complete" by Steve McConnell and "A Philosopy of Software Design" by John Ousterhout.

I second this about Code Complete. (Also I think it's at its 2nd edition, maybe 3rd?)

It's more up to the point instead of going into dogmatic diatribe

It's more evidence based (giving examples, etc)

Go for this one and Bob's your uncle! (or maybe it stops being your uncle, I guess)

> "A Philosopy of Software Design"

What a great book. I second this and add my own "The Pragmatic Programmer: 20th anniversary edition"

"Structure and interpretation of computer programs", its not exactly in the same category but IMO is far better. At least it doesn't make you write tones of one line,single time used functions with 400 character length name.

"The pragmatic Programmer" is one I would recommend.

That, and "Team Geek", in term of relationship with codes and teammates.

The pragmatic programmer is really keen on code generators. Which is the right thing to do. It's also very difficult to do in practice as the languages that are sufficiently impoverished to need external code generators are invariably bound to build tools that can't sanely deal with them.

edit: oh, and also it's hard to avoid people checking in and/or editing the generated code

Uncle Bob,the eternal noob of programming.

Which isn't a bad thing when you write books for noobs, writing resonates more with you when it comes from one of your own.

As an old-timer it is easy to forget that we all started as beginners and had to learn all the things which now are second nature to us. At some point the material which is valuable to a beginner seems trite, obvious and simplistic to a senior.

I am not fond of Clean Code, but I am fond of Clean Architecture. It's a much smaller set of ideas, for a start.

I gave up on Clean Architecture after about one chapter. There's a section where he's graphing the number of lines of code in a hypothetical company's codebase over time - it grows rapidly at first and then it levels off, and he points at this like it means anything, specifically like it's a bad thing and it means the software has become difficult to work in. Also this isn't a line chart, it's a bar chart, and the X axis isn't time, it's unlabeled - eventually, in the text, you find that there's one bar per major release of the software, if that tells you anything about how retro this conception of software development is. Another bar chart shows the number of developers growing rapidly, as if that means anything either... It was just baffling.

I personally find that those two videos are much better at conveying the foundational knowledge needed to invent and understand something like Clean Architecture than the book itself:

https://www.destroyallsoftware.com/screencasts/catalog/funct...

https://www.destroyallsoftware.com/talks/boundaries

It seems unrelated in the surface, but I feel like they explain the "why" of a software architecture in a much simpler way and without the prescriptive and hand-wavy "trust me" nature of most software architecture books.

Just yesterday, when discussing our company's grades, someone joked that the difference between a junior and a senior developer is that a junior developer should learn to know when to use OOP/abstractions while a senior developer should learn to recognize when OOP/abstractions are to be avoided.

Used to be a similar joke in frontend a few years ago when css was at its complexity peak. Where the progression is junior: "I'll just use bootstrap", mid: "I'll write my own css custom tailored to the project", senior: "I'll just use bootstrap."

I also think some of this... attitude? learning? is what go is trying to activate/take advantage of. Everywhere I've worked has had some monstrously experienced senior dev who could easily crack out a solution to a problem of any difficulty but who refuses to use any abstraction more sophisticated than a for loop.

Go says you don't need anything more sophisticated than a for loop, in fact you can't have anything more sophisticated than a for loop. I guess I'm not there yet but it definitely seems suspicious that the people I know who are most into go are very early in their careers or deeply experienced.

I agree, but I would extend it a bit:

For a junior the answer is more "I'll just use bootstrap and customize as much as needed".

While for a senior it's more in line with "I'll just use bootstrap, but you bet I will be on the designer's ass if they ask to customize stuff where it's not necessary."

There is a reason the mid-level developer wanted to write custom CSS. And the reason is that they didn't have the political capital to make bootstrap alone work in a way that is good for the company.

Thanks, this comment accurately captures my discomfort when reading the parts where Uncle Bob was talking. He consistently portrays Clean Code as a programmer friendliness vs processor speed tradeoff, while my impression of Clean Code has never been that it’s slow and programmer friendly, but full of overengineered design patterns that are horrible to read.“Premature optimisation in code flexibility” is a really succinct way of putting it.

I personally find it full of rules that make sense in isolation and can make your code look pretty when you're a solo developer, but are actively making it more difficult to make the program understandable and flexible in the long way.

So many times I've seen a more readable, simpler code turned out to be more efficient as well.

In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around.

The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appear, are also easier to find and fix.

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like.

Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it can even be counter productive to hide details if these details are simpler than the abstraction itself.

In summary, it's all about trade-offs and not over-doing it.

> Many abstraction makes it easier to read for human.

Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.

> Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like.

CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly).

Function calls are slightly more involved, but basically also very, very low level.

you don't write

   if (!condition) 
       goto else_;
   // some code
   goto endif;
   else_:
   // the else block
   endif:
   // More code

Same for loop. That's what we mean by "goto considered harmful".

So why don’t we write plain old assembly then, ad absurdum?

Here are my thoughts in a bit more detail from a previous thread: https://news.ycombinator.com/item?id=35061151

A problem with that is that compiler technology hasn't really progressed to do big whole-program or data-layout optimizations from high level specs.

If we were closer to the model where a program would read its fixed inputs (for the run) and it would be specialized in place for the input using partial evaluation, with profile feedback for data accesses to help transforming the internal data representations to optimize storage requirement and cache access patterns, we would be much more motivated to specify many things abstractly enough to give machine representations of the code and data more freedoms.

The whole C64 scene are shaking their head in disbelief. The CPU couldn't care less about "easy readability" (whatever that even means) of your code. Ever heard of self-writing / self-modifying code? Probably an extreme example, and it can be used both ways - for performance reasons (unroll those loops!) or for abstraction (macros are your friend!).

One thing you have to remember about modern CPUs is that they are not fast 6502s.

I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.

Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre, is of course the reason behind this.

I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.

>> Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour

This is a great comment. Quotable even.

Snake-oil salesmen have always existed in one form or another.

OOP was pushed very strongly in the 90s, for example, and people promising to create massive increases in productivity by providing consulting services for "OOP-ifying" code probably made plenty of $$$ off that fad.

I've seen examples of FizzBuzz Enterprise in practice, eg a small algorithmic challenge that reads in some data and finds a value was split into several files, one class to read the data, one class to run the algorithm, one file to print out the results, etc etc. What was supposed to be one function with less than 50 lines turned into a multi-class multi-file monstrosity. The Java coder doing it couldn't imagine doing it any other way.

> a small algorithmic challenge

For me that depends on the context:

* A challenge for an interview? No wonder people try to insert structure as if it were a bigger project.

* A challenge for a contest? Probably not a good solultion for most point systems.

* A challenge for fun on hackerrank or LC? Whatever you feel comfortable with works.

For structuring a larger system, separating data ingestion, data output and algorithm to work on the data, seems like a fairly entry level separation.

> Clean Code is mostly a premature optimization in code flexibility > in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.

Tying these two together. Clean Code doesn't distinguish between framework code and business logic code. Or more you should write the latter like the former. The problem is writing framework code is hard to do well. It needs to be well thought out, bullet proof, and importantly well documented. That takes a lot of time and effort and running the code under a number of different use cases.

One is better off writing business logic as straight forward and goal directed as possible.

That's interesting, this is the first time I've heard this critique, and I totally agree.

The coding culture around Clean Code seems to put a lot of effort into "building frameworks on top of frameworks" without really admitting it, and the "framework-y bits" are intertwined with business logic, like exposed piping in a building. But business logic should look more like Golang instead.

> I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise.

To be fair, this can be said about any technique. Lots of bad code results from people taking a reasonable principle and applying it religiously rather than judiciously.

On the other side of taking Muratori advice too far, is the story of Mel. Or to be more precise the guy that comes after Mel.

You have a ball of highly optimized mud, that quantum collapses if you glance at it too harshly, and we need it to be USB compatible. By Tuesday. Good luck!

Interesting that he now prefers Clojure, where rules like "function names should be verbs" take a 180 and become don'ts.

This is pretty much my soapbox about DRY. Code is like clay, once it dries it’s not malleable anymore. Components that copy/paste but in doing so are self-contained can be fearlessly changed.

And above a certain size dry works against you because when making changes to component A that requires a slight modification of the behavior or component Q deep in the call stack is so painful because the blast radius is huge. Dry codebases end up slowly accumulating more and more effectively read-only code that makes implementing non-trivial changes require increasing amounts of cleverness until development slows.

I think the more general principle is more to do with code directionality and framework vs library but the motivation to franken-framework your code always seems to be dry.

Having worked with very non dry code where each instance has slight variations but none of the commonalities are captured.. I have to say it can cause a lot of bugs and a lot of headache to maintain.

Not only is it debatable, you never see any type of evidence. And how would you measure it?

Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed.

So you're actually a clean code proponent.

As is usually the case with such debates, it is a debate of differing definitions masquerading as a debate of differing arguments.

Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.

> E.g. preferring inheritance over switch is less readable.

Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex.

Of course there are cases where a switch is the right choice.

Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.

So you are saying context doesn't matter, switch is always better?

If we talk about readability - it is hard to think of a situation when inheritance would be better - it adds an indirection, it hides what's really going on, and at the end of the day the code is also longer and more complex.

However it has some other uses, e.g. when you really want to support adding new cases without modifying the code, e.g when doing a library, you need some kind of polymorphism.

So basically - it is not that abstractions/indirections are inherently bad, but they come at a cognitive cost. And it depends on the context if this cost is justifiable.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

Surprise: I don't use classes. Rust doesn't have them. :P

So, you’ve been arguing for using switch statements, instead of Clean Code’s suggestion of using object-oriented polymorphism, in a context where polymorphism doesn’t exist?

Not at all. Not having classes is not the same as not having polymorphism. Rust supports polymorphism just fine (and one could argue its support for polymorphism is actually much more advanced than that of Java's; but that's not enough reason to use it everywhere).

The greatest trick OOP ever pulled was convincing the world that polymorphism didn't exist outside OOP.

How are structs in Rust any different than classes?

Behavior and data is more separated

A struct only contains data, however you e.g. can define methods on it or implement traits for it No inheritance.

They don’t only contain data though, you can define methods as you said. Yes, there is no-inheritance, but they contain data, maintain state, and allow for defined methods. 90% of the time people are talking about classes, they are talking about that.

I use multiple languages and I always consider the context of programming advice. I recommend a broadened perspective.

In general I would rather maintain code by someone who have read Clean Code than by someone who considers it beneath them because they are too elite.

Afaik, data-oriented approach doesn't use classes to encapsulate behavior.

> Surely this depends on the context?

Yes, it depends on the context. In this case the context is the switch statement described in the https://www.computerenhance.com/p/clean-code-horrible-perfor.... Too bad TFA never mentions it explicitly (other than in the title and in the video). Recently it generated a heated discussion around here.

Agree. Inheritance is a code smell. And clean code does not smell :)

Polymorphism is useful when switch statements are repeated, as a way of eliminating that duplication, not when there’s a single well-encapsulated switch statement.

> Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed.

I think plenty of people love clean code. I love programmer efficiency and readability. But there's clean code and "Clean Code". Some of the code examples from Robert C. Martin's Clean Code book are absolutely atrocious. I would be horrified to find anything so unnecessarily abstracted and overcomplicated in my codebase.

Its precisely because I'm all for readability and programmer efficiency that I find the recommendations in "Clean Code" so bizarre and abhorrent.

His examples use class state as faux-global state and dozens of small one-line methods that "do one thing", but don't really, since they operate on this object state. In the end, it makes it difficult to follow the logic flow, since you have to jump around from one small method to the other to understand what's happening. And clear understandable method naming is of limited help, so it turns into this ravioli code anti-pattern, clean on the surface, but semantically all tangled up.

I think of this as a cross spectrum (terrible, good enough, well done, overdone)

I've seen less production code and more discussions on code that focusses on opposite ends.

terrible readability and maintainability with extreme performance.

v/s.

terrible performance with overdone "design" abstractions.

OTOH, I've seen lot of production code that has good enough design, with well done perf and vice verse.

Not much talk about that stuff.

Like "Reduce. Reuse. Recycle." The logic behind "Make It Work. Make It Right. Make It Fast." is very deliberate.

I want to add reusability and removability. If I for example write some code that connects to a SMTP server to send an e-mail, I probably will re-use it in other places, even in other programs, so the code can't depend on global functions. The code should be independent. Then it also becomes removable and replaceable.

Clean Code led to the development of the VIPER framework, which is a crime it must answer for.

I thought about https://github.com/viper-framework/viper first, but I guess you mean https://github.com/topics/viper-architecture

True. VIPER was the craziest thing I had to deal with when I developed iOS.

Reply on news.ycombinator.com