But how do you know that code do what it is pretend to do without reading it. The article make me think over trusted the other
Good code is rarely read
51–60 of 115 posts
Re: Good code is rarely read
#52This 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…
I would argue that lots of useful code is an utter dumpster fire internally. That doesn't mean we shouldn't strive to do better.
Useful
|
|
Bad-------Good
|
|
Not UsefulRe: Good code is rarely read
#53Those 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…
I think the critics (myself included) perfectly understood that point.
> What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications.
The critique is exactly that this can not happen in real world projects because you can only speculate what requirements for the code base is down the road.
To counter this I usually apply two princinples:
1. Occam's razor - implement the simplest solution
2. Write code that is readable and understandable, so it is easier to change the code with the requirements.
The last being completely opposite to what the author of the article thinks.
The worst thing I can think of is somebody needlessly DRYing up a code base prematurely - this is in my opinion a junior behavior.
Re: Good code is rarely read
#54Earlier quoted context omitted.
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".
People's quality bar differs in height, that's true, but I want to raise one example: https://rclone.org/install.sh
Which is readable, understandable and exceptionally good at what it does for 200 line bash script.
So, there's good code out there.
Re: Good code is rarely read
#55Earlier quoted context omitted.
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
Btw this is called "contrapositive"
Re: Good code is rarely read
#56This 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…
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 th…
Is that possible? I'm not sure if I've ever read code like that before, but maybe that's just me.
Re: Good code is rarely read
#57This 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…
I think you are not reasoning correctly here
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).
Re: Good code is rarely read
#58Is good code never altered or extended? Can good code serve as a learning tool? Can good code explain a complicated process in precise detail?
Re: Good code is rarely read
#59This 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…
I think you are not reasoning correctly here 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.
That definitely implies code can't be good if needs change, which makes no sense to me.
Re: Good code is rarely read
#60This 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…
I think you are not reasoning correctly here 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.