Live data from Hacker News

Good code is rarely read

alexmolas.com

41–50 of 115 posts

Re: Good code is rarely read

#41

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 w…

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.

Re: Good code is rarely read

#42
post #30

Those who are disagreeing with the author seem to not realize that he's just engaging in a bit of navel-gazing wordplay. Sort of like when people say "good programmers should be lazy". What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications. Similarly, I think the author is simply saying that well written, easy to read, easy to understand code…

It is not good to use the word good for serious discussion of any topic.

It's morning, and I really hope I did successfully pull off something close to real irony there.

Re: Good code is rarely read

#43
post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

I did a consulting gig at Allstate around the time of Y2K. I chatted with a senior architect who had been with the company for over 20 years. He noted that there were such a vast array of programs and systems in place, some of which had been running for at least 40 years. I wonder if any of that code had been read, good or bad, for decades. And I am willing to bet that the source code for some of it was lost.

This of course led to no small level of anxiety during the run up to Y2K.

As a side note, while I was there, the dictum came down that there was to be no more assembler programming to be done.

I know what you are thinking. They should just burn the mainframe with fire and rewrite it all. I recommend the book https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/....

Re: Good code is rarely read

#44

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 w…

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 devel…

> 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".

Re: Good code is rarely read

#45
post #30

Those who are disagreeing with the author seem to not realize that he's just engaging in a bit of navel-gazing wordplay. Sort of like when people say "good programmers should be lazy". What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications. Similarly, I think the author is simply saying that well written, easy to read, easy to understand code…

Basically he's saying that if the API is great you rarely need to read the implementation. To which: sure, in some blessed cases where the API was great to start with and nothing changed so you don't need to change the API or the implementation.

Re: Good code is rarely read

#46
post #30

Those who are disagreeing with the author seem to not realize that he's just engaging in a bit of navel-gazing wordplay. Sort of like when people say "good programmers should be lazy". What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications. Similarly, I think the author is simply saying that well written, easy to read, easy to understand code…

It is not good to use the word good for serious discussion of any topic. It's morning, and I really hope I did successfully pull off something close to real irony there.

Something almost like straight out of a Garth Marenghi novel. Now go have that coffee.

Re: Good code is rarely read

#47
post #18

> In conclusion, good code is rarely read. i offer the entirety of sqlite as a counter-example. Based on that project's forum traffic and my participation within that project, i estimate that there are hundreds, if not thousands, of people who actively read that project's C code. That doesn't make it "bad code," that just makes it code which people want to understand (which, in turn, requires reading).

The assertion was "good code is rarely read."

    good code ⇒ rarely read
In that context, "often-read code" does not tell us anything about code quality. And often-read code that's not bad is not a defeater.

Re: Good code is rarely read

#48
post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

The long-lived projects I've seen have some code that mostly works that doesn't have any tests and is hard to grok. Nobody touches it because 1) any change might break something unexpected and 2) if you touch it, you might end up owning it.

I wouldn't call that good code but it's often too good to spend time replacing.

Re: Good code is rarely read

#49
So, according to the author, if I write an ugly script that works very well and offers such a clean and intuitive API, that nobody needs to actually peruse the nightmare hiding within, this is good code. But only for as long as the specs don't change, or no one needs to modify my script. At which point, my good code can become bad code, by virtue of it being unintelligible.

So basically, code can be both good and bad. It just requires that someone opens the box? Schrödinger's code.

I think I'll stick with my own definition, thank you.

Good code: works as expected, strives to be secure, strives to be bug-free, is reasonably efficient for the context it aims to be used in, is concerned with maintainability (this is where readability comes into play).

Re: Good code is rarely read

#50
post #47
post #18

> In conclusion, good code is rarely read. i offer the entirety of sqlite as a counter-example. Based on that project's forum traffic and my participation within that project, i estimate that there are hundreds, if not thousands, of people who actively read that project's C code. That doesn't make it "bad code," that just makes it code which people want to understand (which, in turn, requires reading).

The assertion was "good code is rarely read." good code ⇒ rarely read In that context, "often-read code" does not tell us anything about code quality. And often-read code that's not bad is not a defeater.

On the contrary.

A = "good code"; B = "rarely read"; C = "often read"

A implies B

B is exclusive with C

X leading to C implies X is not A

Post reply on HN