There’s No Such Thing as Clean Code

I have no experience with SonarQube. I guess it's like a linter that's slightly higher level? In that case I'd guess the appeal is that it's reducing the cost of often repeated analysis that is usually done manually, not that the tool itself would make your code great to read.

If that's what it is then I think such tools are "a good servant but a bad master". It does not replace manual analysis, but can be used well to reduce costs of removing common code smells. It still requires a human to work as a judge.

Actually, what people say about code, and how you interpret what they say, depends a lot on what you know about the person in question. I know lots of programmers who can list lots of precise reasons why they think a piece of code is "good" or "clean", but who still seem to lack "good instincts".

Writing code isn't really about ticking boxes, it is about communicating ideas to other human beings. And in that sense, a lot of programmers are to code like some people on the autism spectrum are to social interaction. Lack of instinct pushes us to make up precise rules to try to make sense of things. Rules which do not always work because their application is highly context dependent. And when the rules break down and people still insist the rules are good, you get absurd situations.

For instance is composability good? Well, it depends. On paper this might seem like a simple thing to answer. In a given context composability might mean you have to bolt together a lot of moving parts to get anything done. If 99% of the time you bolt the same parts together the same way, you shouldn't explicitly have to do that. Perhaps composability isn't as important as you think in that instance.

Anyone remember early XML infrastructure in Java? You want to parse an XML file and instead you end up instantiating and plugging together what felt like an awful lot of moving parts you neither needed nor wanted to know about just to parse an XML file? Yes, composability can be good. But as in the XML example, people don't always understand when it ends up being crap. (Actually, you can have both composability and convenience, so I am not trying to construct a false dichotomy here, but the original XML infrastructure was so "socially awkward" that it didn't really offer much convenience)

One may think this is mere nuance. One could also say that uttering a sentence and picking the facial expression and tone of voice to go with it is nuance, and that the words you utter are always what matters. We know this isn't so.

What makes code good is hard to describe. So merely trying to express it more precisely isn't enough. Yes you can say "composability: good". But in a given context it can also mean the code becomes less useful for the purpose in the majority of contexts.

"Clean code" is just a buzzword that people use in interviews, on blogposts aimed at employers, and to make programmers believe they are good programmers, since they already bought the koolaid.

If you break it down to its principles, and then explain its advantages and disadvantages for the problem at hand, then it's respectable; but used as a buzzword it should ring alarm bells.

I'm all for the following the spirit of things, but I also want to take a minute to disagree with the "without being able to explain why" part.

I have worked with people who were super booked up on Go4 and all the design stuff, and yet they can be fairly insufferable to work with when they parrot design advice from all this stuff, precisely because they can't explain why in every given situation. Then, on the receiving end of things, most of the criticism people who are expressing in this forum wrt to uncle bob, do so about examples where they coming from the perspective of something they understand.

I think there is A LOT of value in all of this experience, but it has 0 utility if you don't understand it. In other words, you are much better off not considering how you feel about code at all, and always sticking to doing things because you understand why. (And I'd say 'understand' means in a way that you can explain to someone else who may be skeptical). Context is key... so it's like if you're about to do a live coding demo in front of the board, then yeah, it's ok to comment stuff out - I think that's obvious. Ideally, your outcomes will be much, much better if they're coming from those 'obvious' points of view in any given situation.

Any just to be fair, doing something because you're curious, or it's fun, is just a good a reason as any, it just depends on the context.

This is why, there are other people who I've worked with, who know all that stuff - I'm talking super senior people - and yet rarely ever cite it or even mention it. Usually, they will ask questions because they're patiently trying to get you (or whomever) to see for yourself the same, all-encompassing 'obvious' reason, that overrides all the other important factors in a given context, that they already see. If you ask them why a piece of code that doesn't 'feel right' to you is the way it is, they'll usually have a story about some situation, where they just had to do it that way, and maybe it's bad now but if you were there, and knew what they knew, you would have probably done the same.

So, my point is, yes uncle bob stuff is fairly sound, but no I don't agree that we should follow it if we don't understand it and we're better off almost always sticking to what we do understand. O but also cool analogy about the quick and dirty. I just realized though that if you invert it completely it's like 'slow and clean'.

Was just about to comment with this link. A useful counterpoint whenever Clean Code comes up.

I do think this article makes a lot of valid criticisms and it’s well worth a read. I remember being influenced by it early on but then re-read it as I gained more experience. This article sums up what I felt on rereading.