Live data from Hacker News

Good code is rarely read

alexmolas.com

21–30 of 115 posts

Re: Good code is rarely read

#22
This is only (theoretically) true in the sense that if you build the perfect abstraction, you should not have to think too often about it.

Building good abstractions requires: 1. skill that is in relative terms rare in the profession; 2. enough experience with the problem domain that the abstraction provides the perfect balance between ease-of-use and flexibility as the context changes; 3. a dedicated individual or a small team who nurtures and gatekeeps the evolution of the abstraction obsessively.

For the other 99% of real world cases, the best you can do is try your best to build decent, not-too-leaky abstractions for the problem as you face it today, and the underlying code better be readable because you'll need to maintain it constantly, as will all kinds of other people in varying states of cluelessness.

Re: Good code is rarely read

#23
I have found that what developers consider easy to read varies. So unless you have a lead developer with the political clout to enforce a standard you will end up with a code base with a very inconsistent style.

Unfortunately in the corporate world the people with the required clout rarely want to spend the time necessary to enforce a style.

Re: Good code is rarely read

#24
The best code that I've worked with is always code that is easy to modify. Code that I read rarely could be anything; I'm really oblivious to how good or bad it is until I need to modify it.

Re: Good code is rarely read

#25
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).

But is it good?

Re: Good code is rarely read

#26
As someone who has professionally read code, I don’t think a lot of code gets read very often. It could be also that good code doesn’t take long to read.

Also about the claim that that 10x programmers are fantasy, I call your attention to Fabrice Bellard https://bellard.org/. I have also worked with one or two in my decades of programming career. I probably peak out at somewhere around 0.75.

Re: Good code is rarely read

#27
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 had a similar reaction while reading this, something along the lines of “well, that’s a bunch of idealistic tripe”.

And, honestly, I think that somewhat holds. That said, as an aim, writing readable code that doesn’t need to be read to be used is a good one.

I wrote as much in a quora response almost a decade ago to the question “how does one become a great coder” ( https://www.quora.com/How-does-one-become-a-great-coder-prog... ), and I think it still holds.

However, the other part of that answer was to make the code immensely readable, because we read more code than we write unless we’re incredibly junior or comically superhuman.

Re: Good code is rarely read

#28
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).

But is it good?

It's generally held up as the standard codebase that you can go read to learn how to write "good C", so community consensus appears to be yes.

Re: Good code is rarely read

#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 shouldn't have to be re-read multiple times by the same person. Which is good. The inverse would be that difficult to understand code would have to be read, re-read and studied deeply to actually grok. And thus read a lot. Which is bad.

Post reply on HN