This feels borderline tautological: good code is good because it’s good.
Good or bad, you’re going to end up needing to add new features to this code. Or someone misunderstood an input or output to/from this code and you’ll need to read through it to understand how it’s implicated in a bug.
I think ‘good code is easy to read’ is pretty profound: DRY code with the right abstraction is easy to read. DRY code with the wrong abstraction is hard to read.
Have you ever had the need to read the source code of a tool because it doesn't behave the way it should, and its help and documentation prescribes?
I have been there a couple of times, and how some stuff is handled in these codebases were sad. Sloppy, assumption ridden, or pure, inelegant and fragile hacks.
Even if you're reading a code to modify it, good code is easier to follow and read (point of the junior developer), and as a result, you touch less and less parts of the code to develop it even further.
So yes, Good code is rarely read, or "read less, and in more niche cases".
> Have you ever had the need to read the source code of a tool because it doesn't behave the way it should, and its help and documentation prescribes?
I believe this varies wildly programmer to programmer. I'm often diving into code and reading that when debugging. I've done this with many code bases. It may be debatable if any of them are "good".
There’s a thin sliver of things I have read through that I considered good (even great) that were high effort to read. Things like STL, boost (in parts), numpy… huh. Come to think of it, all things that use C++ templates… and I’m a big fan of templates…
The thing they all have in common is that they are/were overwhelmingly useful to people who didn’t need to go digging inside of them to use or understand them. These are bodies of code for which the behavioral and algorithmic properties were documented thoroughly, bodies of code that generalize to wide ranges of applications.
Still, we’re not all writing STL core classes every day. Sure. Write code so good it doesn’t need to be read. Write code so good that people want to read it. And write code that, when read, is welcoming, comprehensible, and considerate of others or yourself in the future.
Saying the first thing shouldn’t mean unsaying the other things… Something our author may learn over time.
There’s probably a time axis that comes into play, at least for a large number of projects. Bad code which is immediately useful, even indispensable, can decline in utility fairly sharply the parameters which determine its usefulness change faster than it can be adapted to meet those needs or goals.
There's definitely a time axis that comes into play. I'd say that all tech debt should be (but probably isn't always) in that top left quadrant. Like they say, good/fast/cheap - pick two (if you're lucky).
It's because they are using "read" to mean "understood/interpreted" in the sense that the reader is executing the program in their head.
In their last paragraph:
It should be so well-structured and named that its purpose and functionality are immediately apparent [when read]. This minimizes the need for others to read through **and interpret** the code, allowing them to use it more effectively.
(emphasis added)
So the point is really: "Good code should be so apparent that when the reader reads it they do not have to be a human interpreter."
Adding features to a code means it was incomplete. Misunderstanding input/output usually means it is poorly documented or lacked a good API. A good API works at the surface (in/out) and not in the volume.
Really good code solves a problem completely. I have worked with such code and yes almost nobody ever goes into this code (and makes changes).
> Adding features to a code means it was incomplete
In practice this isn't true. The code may have been perfect and complete according to the business requirements of 1 month ago. But the business requirements of 1 month ago and today are often completely different.
I'm not familiar with many systems or backend software that are still actively used, multiple decades old, and not still receiving updates. If it's not even a decade old, it's not old enough to say requirements won't change.
Missing feature implies an error at the Requirements level.
This does not impact readability or the idea of "good code" in my opinion.
You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.
What about changing features? E.g. a feature has to change 2 years down the line because certain laws are passed and this changes how the business logic should behave.
Well, what's wrong with code being incomplete at some point of time?
Is it not waterfall enough? Is it too much learning from customers? Is it too small PRs of duration less than 1-6 months? Is it not enough premature optimization?
You are being a pedant. "Good" can describe anything that meets high standards or performs well in its context, e.g. as 'good game' or 'good weather.'
Your excessive focus on minor linguistic nuances is counterproductive. It's more important to understand the overall message than to get bogged down by trivialities, which everyone here seems to be able to do — except you.
Moreover, by repeatedly correcting language, you give off an 'I'm smarter than you' vibe, which isn't conducive to a productive conversation.
Good or bad, you’re going to end up needing to add new features to this code. Or someone misunderstood an input or output to/from this code and you’ll need to read through it to understand how it’s implicated in a bug.
I think ‘good code is easy to read’ is pretty profound: DRY code with the right abstraction is easy to read. DRY code with the wrong abstraction is hard to read.