[flagged]
[deleted]
Good code is rarely read
81–90 of 115 posts
Re: Good code is rarely read
#82This 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).
I thought you extended, not edit, really good code to achieve that
Re: Good code is rarely read
#83This made me think of two tangentially related things about code quality and reading which are each 10 years old!
Peter Seibel repeatedly tried to start "code reading groups", but found that they didn't quite work, because while everyone agreed that there was much to be learned from code bases, and that many advised "reading" code, most real code doesn't support "reading" so much as "decoding" or perhaps interactively exploring.
https://gigamonkeys.com/code-reading/
Robert Heaton had a fun post about code reviewing without being able to actually read the specifics of the code. With only a blurry view of the structure of code, one can get a sense of its likely virtues and opportunities for improvement. https://robertheaton.com/2014/06/20/code-review-without-your...
Kind of in the spirit of both, I love code where you don't _have_ to read most of it because:
- class names, generic parameters, etc, make it clear what classes represent
- method names and signatures make it clear how they're to be used; there are no surprises or gotchas in the specifics of the implementation that foist cognitive complexity onto callers, etc
- the right amount / granularity of structure exists, such that when you do need to read something, the section is moderately sized; there's not some enormous, entangled method that's actually doing 5 things at once. Modularity limits the scope of reading.
But also, when you do need to understand implementation specifics, good code acknowledges that reading is likely not "enough"; good code gives straight-forward on-ramps to interact and experiment with it. It doesn't force you to hunt for a bunch of environmental variables, configurations that are examined by an IoC layer, or magically materialize a file containing a specific serialization of a well-formed record just to invoke.
Re: Good code is rarely read
#84This 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]
You are being a pedant. "Good" can describe anything that meets high standards or performs well in its context, e.g. as 'good game' or 'good weather.'
Your excessive focus on minor linguistic nuances is counterproductive. It's more important to understand the overall message than to get bogged down by trivialities, which everyone here seems to be able to do — except you.
Moreover, by repeatedly correcting language, you give off an 'I'm smarter than you' vibe, which isn't conducive to a productive conversation.
Re: Good code is rarely read
#85I think the author actually meant
"Good code is rarely read twice."
Re: Good code is rarely read
#86Earlier 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).
Let me guess, you work on game engines?
I have but I dont currently. I am guessing the implication is that game engines have good code while other subsectors do not.
Re: Good code is rarely read
#87Earlier 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).
[flagged]
Re: Good code is rarely read
#88In the real world, code is read often and for many reasons. The main ones I can think of are: 1) To understand the system without necessarily wanting to change anything. This is common with new employees or anyone wanting to learn more. 2) The system often needs tweaks, bug fixes or new features. Each of these normally requires that the code in question is read by several people several times. 3) The architecture is…
I agree with the first one but the other 2 are basically what the author is speaking out against.
Some change/rework is unavoidable, but if code is good, then it should be relatively rare. Modularity isn't sufficient for code to be good. It's difficult to have truly 'loose coupling' without 'high cohesion'; each module should have distinct and well-defined responsibilities. My test for high cohesion is the question: "Is this module easy to describe to a user with limited technical abilities?"
If modules are both loosely coupled and high cohesion, you'll find that you rarely need to change the code, or won't need to change it much, even after substantial refactorings. This is because such modules provide a near-optimal level of abstraction. Interfaces of such modules tend to be simple (a relatively small number of simple parameters, e.g. primitive types); this is what makes the modules easy to substitute.
For example, consider a database client library, the most powerful method is for running queries against the database; this method typically requires only a single argument as a query; a string, though it will also typically support an object/map as second argument to substitute values into the query. How often do you need to change the database client library because of a refactoring? You could literally pivot your entire business model from a social media app to an enterprise CRM and you wouldn't have to change a single line of code in your database client. You might change how you use your database client within your back end logic, but you won't have to change the implementation of the client itself.
There are many less extreme examples though where a module can handle very significant changes to your business without having to be modified at all. Maybe your business pivoted from being a professional/business social media app to being focused on friends and family; it might change some aspects like friend discovery, algorithm recommendations, banning, etc... But you should be able to keep most of your existing code if your code is good quality.
My definition of good code is "Code that is resistant to change when faced with requirement changes." Though there is a lot of overlap with "Code that is rarely read."
Re: Good code is rarely read
#89Earlier 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 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.
This falls outside of my experience. I am systems or "backend".
Re: Good code is rarely read
#90Earlier 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
Not useful code is always bad, because you never had to write it. It is just a waste.