71–80 of 115 posts
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…
Earlier quoted context omitted.
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 Useful
Earlier 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.
Your approach is I guess valid for self contained algorithmic code, i.e. 0.000001% of code out there.
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…
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).
There’s a similar concept in management where the ineffective team requires additional staff to complete their work, which means that their culture “infects” the majority of the employees in the organisation.
Once I noticed this pattern, I can recognise it everywhere.
E.g.: JavaScript gets an enormous amount of industry attention because it is so inefficient and clumsy. If it was a good, mature language it wouldn’t need an endless parade of libraries, frameworks, tools, blog articles, vendors, and tutorials.
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…
[flagged]
This 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…
They are called game engines or physics engines etc. Everyone works with a ton of very well made code every day, you just don't think much about those since they don't cause problems.
Earlier quoted context omitted.
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 Useful
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.