Hacker News Reader

Comment by sarchertech | Hacker News Reader

>Clean code optimizes for improving time-to-market for those features

Does it though? Where's the evidence for it? The vast majority of people I've worked with over the last couple decades who like to bring up "clean code", tend towards the wrong abstractions and over abstracting.

I almost always prefer working with someone who writes the kind of code Casey was than someone who follows the clean code examples I've spent my career dealing with. I've seen and worked with many examples of Data Oriented Design that were far from unmaintainable or unreadable.

View on HN

Completely agree. These rules simply do not lead to better outcomes in all cases. Looking at the rules and playing Devil's advocate for fun:

> Prefer polymorphism to “if/else” and “switch”

Algebraic data types and pattern matching (a more general version of switch), make many types of data transformation far easier to understand and maintain (versus e.g. the visitor pattern which uses adhoc polymorphism).

> Code should not know about the internals of objects it’s working with

This is interpreted by many as "don't expose data types". Actually some data types are safe to expose. We have a JSON library at work where the actual JSON data type is kept abstract and pattern matching cannot be used. This is despite the fact that JSON is a published (and stable) spec and therefore already exposed!

> Functions should be small

"Small" is a strange metric to optimise for, which is why I don't like Perl. Functions should be readable and easy to reason about. Let's optimise for "simple" instead.

> Functions should do one thing

This is not always practical or realistic advice. Most functions in OOP languages are procedures that will likely perform side effects in addition to returning a result (e.g. object methods). Should we also not do logging? :)

> “DRY” - Don’t Repeat Yourself

The cost of any abstraction must be weighed up against the repetition on a case-by-case basis. For example, many languages do not abstract the for-loop and effectively encourage users to write it out over and over again, because they have decided that the cost of abstracting it (internal iteration using higher-order functions) is too high.

my 2 cents: I don't see algebraic data types as strictly superiour. It's just the other side of the polymorphic coin: there is open and closed ploymorphism. Open polymorphism happens with interfaces, inheritance, and typeclasses- the number is unlimited. Closed happens with ADTs - an enumeration of the cases.

Open is great for extensibility: libraries can be precompiled, plugins are possible. Changes don't propagate - it is ""forward compatible"" which is great for maintaning the code.

Closed on the other hand is great for matching. Finite is predictable & faster. Finite is self-contained and self-describing because it exposes the data types without shame.

The purpose of the visitor pattern is now clear: it closes the open polymorphism for a finite set. Great, now we only need one kind and we still get matching. Or is it the worst of two worlds? Slow & incomprehensible and all changes propagate everywhere.

So which one is better? Neither. But the reality is that all old imperative languages with polymorphism chose the open kind - the kind that adds more features because it was needed for shared libraries. Leaving you to build any pattern matching yourself and to burn yourself with the unmaintainable code.

If people get burned, they learn. First they say don't do that and only then they replace the gas stove by induction.

> So which one is better? Neither.

I agree. And your "2 cents" demonstrates a depth of understanding greater than that offered by these rules.

You are confounding three separate skills. Finding the right abstractions is an art, whether you write clean code or not. Writing high performance code is another art.

A really good developer writes clean code using the right abstraction (finding those tends to take the most time and experience) and drop down to a different level of abstraction for high performance areas where it makes sense.

The fact that bad developers suck and write bad code no matter if they use clean code or not does not reflect on the methodology

If there are no hard measurements I can use to determine the value of "clean code" then I fall back on the results of produced by people who say they are writing clean code. There is no realistic way to objectively measure coding styles completely isolated from the people writing the code.

I personally haven't seen value from that coding style. There may be some platonic ideal clean code that is better than other methodologies in theory--it is likely that my sample is biased--but from what I've seen, the clean code style tends to lead most developers towards over abstraction.

I agree but i think that mostly comes from Clean Code being kind of required reading for junior developers, that lack the experience to understand those concepts in context. No methodology is perfect, and there are always cases where one needs to break out of them, to know when to do that comes with experience.

For juniors which have no experience, any sane methodology is better than none, since otherwise you get even more of a mess.

That said, Clean code has some great advice, some mediocre advice and some frankly bad advice, but the authors point are largely irrelevant to 99 % of software engineering.

I think this is the key insight.

It is easier to find an abstraction if we lay out what the program is doing all in long functions, that just "do what they do" until you figure out what needs to be abstracted.

Reply on news.ycombinator.com