Is good code never altered or extended? Can good code serve as a learning tool? Can good code explain a complicated process in precise detail?
[flagged]
Good code is rarely read
61–70 of 115 posts
Re: Good code is rarely read
#62This 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…
[flagged]
Re: Good code is rarely read
#63Earlier quoted context omitted.
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.
Adding features means it was incomplete. Good code can essentially always be built upon instead of modified.
Re: Good code is rarely read
#64This 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…
[flagged]
Books and movies have no morals and so they cannot be good or bad.
Re: Good code is rarely read
#65This is only partially true, and not relevant in most cases.
In game development, my primary field of expertise, the notion of a static codebase is largely a myth until the project nears completion. Most projects span several years, during which the code undergoes continuous evolution.
In this context, code must be as fluid/malleable as possible, because its entire structure is likely to change several times, to add and remove features, to improve performance, to fix bugs and sometimes for even deeper rework.
If the already written code is hard to read, these iterative modifications become unnecessarily arduous.
Re: Good code is rarely read
#66This 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).
Let me guess, you work on game engines?
Re: Good code is rarely read
#67Earlier quoted context omitted.
> 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.
Adding features means it was incomplete. Good code can essentially always be built upon instead of modified.
is "building upon" different from "adding features", in this new terminology?
Re: Good code is rarely read
#68Re: Good code is rarely read
#69This 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…
[flagged]
In case it isn’t obvious, I’m reasonably confident that most everyone else is discussing “good” as an assessment of quality, not morality.
There are actually aspects of morality which might be discussed, but I generally don’t think it’s the topic at hand.
Re: Good code is rarely read
#70Earlier quoted context omitted.
> 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.
Adding features means it was incomplete. Good code can essentially always be built upon instead of modified.
But code can be complete and then become so-called incomplete because, again, needs change.
eg someone releases a new file format. You believe ffmpeg is bad code?