There’s No Such Thing as Clean Code

In the literal sense private is default though. I wonder why. Lexical sorting of private, protected and public?

It makes almost no sense to have all private class fields and methods. The only thing I can think of is fat handles with friend classes or functions.

Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written, vs what your code does? Given that, where should you put most of your effort?

This is a classic mistake that relatively junior people make. There's a body of research out there that goes back more than half a century that gives you plenty of heuristics, metrics, and other ways to classify code as good at bad in all sorts of interesting ways. Most engineers have barely any awareness of this and instead absorb vague notions of "good" and "bad" things from others over time.

Junior frontend engineers coming fresh out of college are typically very ignorant on this front. Ignorant as in they have yet to rediscover this wealth of information through reading books, articles, etc. As well as by messing up a few code bases or by absorbing it from their more senior peers through e.g. code reviews or venting on blogs, twitter, and whatnot. That is because this stuff just isn't taught in a lot of places. Or if it is taught at all, it isn't taught very well typically by people who don't do a lot of coding. I know, because I used to be such a person before I switched to doing some actual software engineering 20+ years ago.

Combined with the arrogance of youth and the tendency to label everyone above 27 as a senior, unclean code is rather common. And even acknowledging it is bad is a problem when you lack the intellectual tools to reason about code quality.

It's not a matter of taste to consider high coupling and low cohesiveness a bad thing. It's easy to see when that is out of wack (long list of imports, 4000 line source files, etc.). It's easy to measure as well if you care too but typically redundant to do so. Likewise, having a high level of indirection would be a violation of e.g. Demeter's law. Likewise deep inheritance hierarchies aren't great (just don't). And that is equally easy to observe. Finally having a large function with insane nesting of loops, ifs, and what not produces a high complexity that you can measure or just look at it an go "gee, this looks rather complicated". It's not that hard to spot bad code if you know what to look for. It's also not that hard to improve such code once you understand why it is bad.

Every bad code base you've ever seen probably has a lot of things that you can objectively point at and say this just isn't very clean because X. It stops being a matter of esthetics when you phrase it like that. And the broken windows theory combined with a level of ignorance/indifference usually leads to more bad code making it into the code base.

There are plenty of studies that will suggest that having a lot of hard to read code does not help maintainability, extensibility, and a few other -ilities. Those are called quality attributes. And yes, you trade them off sometimes. There are yet more studies that point to maintenance as a dominant thing in overall software cost. There are also several standards that have lots of things to say about quality attributes. People developing e.g. embedded software for cars or medical devices tend to take that stuff rather seriously.

But understanding that high cost is bad is relatively uncontroversial. Producing code that isn't very clean leads to higher cost. It's not about the esthetics but about cost. Both current and future.

Sometimes you can trade that cost off. E.g. if you are going to throw away your UI code in 6 months, it's OK to put a few cheap fresh out of college people on that project. It's going to be a dumpster fire in terms of code quality but it might be useful as an MVP and you'll replace it anyway before it gets out of hand. I make tradeoffs like that all the time. And I also use such projects as an opportunity to train up young people quickly. Let them make a few mistakes and then show them how to fix it.

Back in university I had an experience that was really instructive.

For a project we had to write a program that differentiates mathematical equations.

I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created.

Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could.

In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in.

This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite.

As they say "measure twice, cut once".

Writing style and thoroughness etc. of the comments could still be a give-away.