Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means, but that doesn't mean that all writing is equal or that "everything is a tradeoff"—and, like you said, it doesn't mean we need to deeply analyze every piece of writing to draw useful conclusions about it.

My view is that while there is definitely a subjective aspect to quality—whether in code or in writing—a larger portion is objective, just hard to formalize or quantify. Just because we can't measure something directly or because we can't all agree about it in every instance doesn't mean it's subjective. There are a lot of things we can't know exactly but that are still objective, so why not writing or code quality as well?

> some writing is clearly better and some writing is clearly worse This is a presumption, and one that I don't share

Like music and other forms of art, different styles appeal differently to different audiences. Many people find the language that 8 year olds write in to be terrible, and some people find it endearing and honest and meaningful. Software is no different in my opinion

Audience always matters

> Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means

There are different writing styles (and so guide styles associated) for different objectives. Eg, journalism, with a pyramid model designed and refined to ease the process of assimilating information which is different from the playscript style model designed to give general instructions on how to flesh out and enact events.

Both these styles (I intentionally chose for their more obvious rules and usage) have different hard-and-fast rules and applying one instead of the other wouldn't work.

Now, there will be a subjective quality but there are also objective qualities to writings produced with these styles (structure, count of words, choice of wording for description, timeline of events reported, etc.).

Now, of course regarding novels, storytelling, the newyorker, writings that are intended to be read, alone, to tell a story, to convey more than facts and the most objective description of reality yada yada.

And then there are technical manuals. I think code is a technical manual for two kind of audiences: humans and computers, so compromises are made and rules for clarity and brevity can be layout.

> There are a lot of things we can't know exactly but that are still objective

Hmmmmmm not sure about that. AFAIK anything that we either can't measure objectively, or don't yet know how to measure objectively, is a subjective measurement, even if that measurement is subject to an objective apparatus (observer effect experiments; the measurement is subject to the circumstances of measurement)

Totally open to being wrong and you being right tho. Any examples come to mind for you?

Writing would be a great metaphore only if you write the code alone and when you declared it finished, you never need to come back and add new things/remove old things or fix bugs in it.

I don't see how that invalidates the metaphor. For any version of code you can evaluate clean-ness. Writing is also not immutable, professional authors make hundreds of versions before publishing.

Of course books get 1 major release. So while ability to maintain and change is much more important in software, that is by far not the only factor for clean-ness, and I'd say hardly the most important.

I'm not giving up on clean code, but at the last 5 years I pursuit separation of pure function and unpure function more than clean code. It makes easier to debug / unit tests.

That sounds like clean code ;)

> There's just too many things to consider and viewpoints to take, we'd be trapped in analysis paralysis forever, as you can continue it to no end. There's never a point where the analysis will be "done".

I agree with you there - but this makes it even more bizarre that there are now tools (e.g. SonarQube) trying to automate this analysis. Of course, linters are a undeniably useful, but stuffing arbitrary rules into a tool which then gives grades to your code based on a strict interpretation of those rules is a bridge too far. I mean, can you really take software that uses terms like "blocker code smell" seriously?!

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.

Like writing, code gets better with mulling over most parts (for a long time) and rewriting a lot after insights were properly formed. When you start something, you are exploring; how can you expect that that code will be anywhere close to an ideal situation that time? People say refactoring but in my opinion that is not radical enough; you will be able to redo problems you encountered by maybe completely re-architecting the solution. This luxury is not really a thing many people can afford ofcourse; we just make stuff work well enough to get paid. And it shows.

Subjective terms like "clean", "ugly" really hurt our field. OTOH the following attributes are objective and verifiable:

- the code complies with coding conventions in force

- it is correct

- it is not inefficient

I would really love coworkers stick to these three criteria during reviews.

an important thing to realize with this analogy is the difference in purpose between code and writing. Writing is meant to be read whereas code is meant to specify a program. For people who read code like writing this makes sense but when the focus is more on the resulting program the concerns change a lot.

People are rewriting things all the time for various reasons.