[HN Gopher] Good code is rarely read
___________________________________________________________________
Good code is rarely read
Author : alexmolas
Score : 70 points
Date : 2024-06-15 13:26 UTC (9 hours ago)
(HTM) web link (www.alexmolas.com)
(TXT) w3m dump (www.alexmolas.com)
| davydm wrote:
| 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.
| bena wrote:
| Not just long-lived projects. Working on bespoke, internal
| systems means you're never truly done. And what you've done a
| month ago may not be what's wanted now.
| madsbuch wrote:
| Exactly my thoughts.
|
| The reason why good code is code that is easy to read, is
| because products evolve, and so does the code.
|
| Suddenly the taxonomy of that enum starts to shift, and the
| name that was perfect yesterday does not make sense tomorrow.
|
| These changes happen gradually and a basic acceptance of the
| code base not being on par with the product understanding is
| necessary in order to have any kind of velocity on not only
| spend time refactoring.
| jeremywho wrote:
| I don't think you read the whole article. I had the same
| thought as you from the headline, but they gone on to state
| that good code is so easy to read when you need to make changes
| that you don't have to go through it multiple times to make the
| required changes.
| chaboud wrote:
| 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.
| wglb wrote:
| I did a consulting gig at Allstate around the time of Y2K. I
| chatted with a senior architect who had been with the company
| for over 20 years. He noted that there were such a vast array
| of programs and systems in place, some of which had been
| running for at least 40 years. I wonder if any of that code had
| been read, good or bad, for decades. And I am willing to bet
| that the source code for some of it was lost.
|
| This of course led to no small level of anxiety during the run
| up to Y2K.
|
| As a side note, while I was there, the dictum came down that
| there was to be no more assembler programming to be done.
|
| I know what you are thinking. They should just burn the
| mainframe with fire and rewrite it all. I recommend the book
| https://www.amazon.com/Kill-Fire-Manage-Computer-
| Systems/dp/....
| drewcoo wrote:
| The long-lived projects I've seen have some code that mostly
| works that doesn't have any tests and is hard to grok. Nobody
| touches it because 1) any change might break something
| unexpected and 2) if you touch it, you might end up owning it.
|
| I wouldn't call that good code but it's often too good to spend
| time replacing.
| bena wrote:
| I don't think this is a good rule of thumb.
|
| Code that does what it should is rarely read. Until you need to
| change it. And it may not be changing due to it being incorrect.
| If an attendant system gets replaced, you may have to change all
| the other systems it has touched. Business requirements may have
| changed. Stakeholders may have changed.
|
| There are plenty of reasons for code to change beyond there being
| a bug.
| jeremywho wrote:
| I don't think you read the whole article. I had the same
| thought as you from the headline, but they gone on to state
| that good code is so easy to read when you need to make changes
| that you don't have to go through it multiple times to make the
| required changes.
| rty32 wrote:
| So we are just talking about the "WTF per minute" metric:
|
| https://commadot.com/wtf-per-minute/
| SatvikBeri wrote:
| Recently I was going through the codebase that our company has
| spent the last 7 years developing, trying to find examples of
| code we reuse a lot. This turned out to be very unintuitive: the
| functions we actually reused the most had practically fallen
| below the threshold of conscious thought. They almost "just
| work", so I hadn't realized how much I'd been using them.
| ziggy_star wrote:
| Back in times of yore there was briefly a trend of "literal
| programming" in the javascript universe. They actually bothered
| to present their little libraries nicely.
|
| Like so: http://underscorejs.org/docs/underscore-esm.html
|
| It goes back to IBM days where annotated code would ship in hard
| binders and was meant to be flipped through.
|
| Sadly this has not caught on. How do you guys go spelunking in
| interesting codebases? I always wonder why there's isn't more
| tooling around this.
| ck45 wrote:
| It was originally invented by Donald Knuth in 1984. He created
| Web (not the World Wide Web) for this purpose.
|
| See e.g. http://www.literateprogramming.com/
| jeremywho wrote:
| I agree. Clever abstractions are often the antithesis of this.
| stuckinhell wrote:
| That is a bold statement. I'm 100 convinced that it's based on
| your code architecture.
|
| Good code in my systems are ones that don't need to be touched or
| read very often, and the fluid/unknowns parts are decoupled
| elsewhere. Sometimes business requirements issue, Sometimes
| difficult technical problem.
| v3ss0n wrote:
| That doesn't make sense . A good quality code is ready a lot,
| internally we reference good code as example for new employees
| and it is also being read, reused again and again. The author
| looks like just non-engineer manager.
|
| The bad code is read a few times and refactor as soon as we get a
| chance.
| zodiac9936 wrote:
| At a minimum, new code should be ready more than it is written.
| It's written once, then reviewed by the author and by one or more
| peers on your team.
|
| Not doing code review on a collaborative project? You're already
| setup for failure...
|
| OP's point of view is valid if they are the only one working on
| the project. Only you are responsible for your low standards.
| aaronbrethorst wrote:
| 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
| wrong abstraction is hard to read.
| ModernMech wrote:
| 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 the point is really: "Good code should be so apparent that
| when the reader reads it they do not have to be a human
| interpreter."
| Sakos wrote:
| Is that possible? I'm not sure if I've ever read code like
| that before, but maybe that's just me.
| bayindirh wrote:
| 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 developer), and as a
| result, you touch less and less parts of the code to develop it
| even further.
|
| So yes, Good code is rarely read, or "read less, and in more
| niche cases".
| gravypod wrote:
| > 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".
| bayindirh wrote:
| 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.
| pydry wrote:
| Most essays about good code seem to end up being tautological.
|
| The good ones dont.
| chaboud wrote:
| 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 are bodies of
| code for which the behavioral and algorithmic properties were
| documented thoroughly, bodies of code that generalize to wide
| ranges of applications.
|
| Still, we're not all writing STL core classes every day. Sure.
| Write code so good it doesn't need to be read. Write code so
| good that people want to read it. And write code that, when
| read, is welcoming, comprehensible, and considerate of others
| or yourself in the future.
|
| Saying the first thing _shouldn't_ mean unsaying the other
| things... Something our author may learn over time.
| aaronbrethorst wrote:
| 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
| eyelidlessness wrote:
| 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.
| aaronbrethorst wrote:
| There's definitely a time axis that comes into play. I'd
| say that all tech debt should be (but probably isn't
| always) in that top left quadrant. Like they say,
| good/fast/cheap - pick two (if you're lucky).
| earnesti wrote:
| Not useful code is always bad, because you never had to
| write it. It is just a waste.
| petermcneeley wrote:
| 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).
| x0x0 wrote:
| > _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.
| jacoblambda wrote:
| Adding features means it was incomplete. Good code can
| essentially always be built upon instead of modified.
| exe34 wrote:
| is "building upon" different from "adding features", in
| this new terminology?
| x0x0 wrote:
| 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?
| oblio wrote:
| Laws change, business requirements change, network
| protocols/external APIs change, ...
|
| Your approach is I guess valid for self contained
| algorithmic code, i.e. 0.000001% of code out there.
| wavemode wrote:
| > 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.
| petermcneeley wrote:
| This falls outside of my experience. I am systems or
| "backend".
| aaronbrethorst wrote:
| Let me guess, you work on game engines?
| petermcneeley wrote:
| I have but I dont currently. I am guessing the implication
| is that game engines have good code while other subsectors
| do not.
| frapaconi wrote:
| I'm also going to nitpick here. Really good code, does that
| mean it's like Jesus good? The code will save people? Or is
| it just good as in people like it because it's nice to them?
| petermcneeley wrote:
| https://biblehub.com/mark/10-18.htm
| cjblomqvist wrote:
| I thought you extended, not edit, really good code to achieve
| that
| frapaconi wrote:
| For what it's worth, code has no morals and so the word good is
| not applicable.
| aaronbrethorst wrote:
| Books and movies have no morals and so they cannot be good or
| bad.
| frapaconi wrote:
| Precisely! Well, I suppose Arnold runs bad code in
| Terminator. Well, I suppose suppose it might be good code
| according to Skynet.
| eyelidlessness wrote:
| 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.
| xwowsersx wrote:
| 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.
| frapaconi wrote:
| I'm going to nitpick here again. Good is not the word to use.
| Now you're saying "good code is easy to read." No. Readable
| code is easy to read. Efficient code may not be easy to read.
| Is efficient code "good"? Satan is bad, is bad code satan?
| aaronbrethorst wrote:
| I know this can be hard to accept, but language is fluid and
| words have many different ways of being used.
| strnisa wrote:
| In 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
| normally not perfectly modular, so changing one part often
| requires one to understand and tweak the neighbouring parts of
| the system, too.
| jongjong wrote:
| 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."
| sgbeal wrote:
| > 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).
| protomolecule wrote:
| But is it good?
| jacksnipe wrote:
| 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.
| drewcoo wrote:
| 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.
| mekoka wrote:
| 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
| Izkata wrote:
| Btw this is called "contrapositive"
| cess11 wrote:
| So code that gets read a lot isn't good code, got it.
|
| This means that core algorithm bundles in business applications
| that necessarily carry a lot of complexity and need lots of
| careful maintenance over the decades can never reach the status
| of good code.
|
| On the other hand, the twenty lines of bash I use to hook mpv
| into SomaFM streams are very good code.
| WillAdams wrote:
| There is an entire discipline on the idea that the effort to make
| code easily read/understood will result in source code which is
| easier to maintain and write:
|
| https://literateprogramming.com/
|
| (or if that's off-line, see:
| https://en.wikipedia.org/wiki/Literate_programming )
|
| and published books which exist so that folks can read the source
| code of programs:
|
| https://www.goodreads.com/review/list/21394355-william-adams...
| lelandfe wrote:
| Mind the s: http://literateprogramming.com/
| EugeneOZ wrote:
| The person you interviewed gave a better definition. "Code that
| is easy to read" is often a good code. Code that is rarely read
| only exists in the manager's imagination.
| rodelrod wrote:
| 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.
| treespace8 wrote:
| 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.
| parasti wrote:
| 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.
| wglb wrote:
| 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.
| shinzui wrote:
| The premise of the article is flawed. I read a lot of code, and
| that's how I learn and discover new things.
| rmah wrote:
| 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.
| CodeMage wrote:
| The corollary of the author's argument would be that no C++
| code is good ;)
| AtlasBarfed wrote:
| It is not good to use the word good for serious discussion of
| any topic.
|
| It's morning, and I really hope I did successfully pull off
| something close to real irony there.
| karmakurtisaani wrote:
| Something almost like straight out of a Garth Marenghi novel.
| Now go have that coffee.
| rodelrod wrote:
| Basically he's saying that if the API is great you rarely need
| to read the implementation. To which: sure, in some blessed
| cases where the API was great to start with and nothing changed
| so you don't need to change the API or the implementation.
| madsbuch wrote:
| 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.
| SuaveSteve wrote:
| Perhaps another reason for good code being hardly read is that
| good code doesn't break anything.
| angarg12 wrote:
| Code quality and how often it is read are mostly orthogonal.
|
| You can have an stinky old piece of legacy software that no one
| ever reads because that system is deprecated and slowly getting
| phased out, and we can live with it in the meanwhile.
|
| You can have the most elegant a beautiful piece of code that gets
| read a lot, because it is in the critical path of a very active
| and rapidly evolving system, and people need to reference, modify
| and extend it a lot.
|
| However there is a crucial way where OP is wrong: there is a pull
| and push between code quality and how often it is read. If your
| code is a legacy big ball of mud, people will be less inclined to
| touch it, probably going to the extend of rewriting the whole
| thing. On the other hand when code is well written, people are
| less afraid of digging into it.
|
| Lastly, even if OP thesis was correct, I don't know think it
| would change anything. Strive to write the best code you can
| within reasonable constraints, independently of how much other
| will read it (which in my experience is almost always
| underestimated).
| tetha wrote:
| Hm, I would agree more with the overall headline and conclusion
| if it was about time spent reading code.
|
| The best code and code bases allow you to quickly understand how
| they are structured and don't necessarily hold subtle, nasty
| surprises - or at least make it obvious if something is a nasty,
| subtle surprise. Those code bases tend to be a quick read.
|
| The bad functions and code bases require you to carefully
| consider every little aspect of every single line in detail. And
| I don't just mean "read every line", I mean "Dissect lines based
| upon language specs, and also keep in mind this is interacting
| with 5 different other parts of the code base. Or not. Who
| knows?" In such code bases, just figuring out what something does
| tends to be a slog.
| lsaferite wrote:
| > Good code is so ergonomic that you almost don't need to read
| it; you just use it.
|
| This is a poor world view and is what leads to unwieldy systems
| with weird interactions that are buggy in just the right
| situation.
|
| I understand what the author was trying to express, but the
| sentiment is poorly expressed. They conflate "used"/"run" with
| "read" several times. IME, good code is readable code, but not
| all readable code is good code. Clever code is normally much less
| readable. At the end of the day, the lifecycle of any code you
| produce is such that it will generally be maintained far beyond
| the time is was written. To me that means you need to write code
| with maintainability in mind. If you cannot read and understand
| the code, how can you expect the effectively maintain the code?
|
| Simply having a clearly defined function name, arguments, and
| documentation doesn't mean you can ignore making the innards
| maintainable.
|
| Finally, as others have pointed out, you _want_ your colleagues
| reading good code so they can learn to write better code. No
| matter your level, you should never stop learning to be a better
| developer.
| preommr wrote:
| Genuinely, one of the worst think pieces I've seen this year.
|
| How does the author presume to know how to use something without
| being able to read it's interface or related documentation? The
| very things that make something easy to use, like clearly naming
| things, also makes it easy to read.
|
| I would even argue that reading what the underlying code does is
| always good practice. Even if you think you know how something
| works, confirming it can avoid nasty bugs. Not to mention all the
| projects that are non-trivial and have enough complex behavior
| that reading the code is the best way to understand what it does;
| where there is no other way for it to be easy to use according to
| the author. There's also lots of other benefits, such writing
| code that is more consistent and more semantic with the
| underlying style.
|
| Just horrible, horrible advice.
| mekoka wrote:
| So, according to the author, if I write an ugly script that works
| very well and offers such a clean and intuitive API, that nobody
| needs to actually peruse the nightmare hiding within, this is
| good code. But only for as long as the specs don't change, or no
| one needs to modify my script. At which point, my good code can
| become bad code, by virtue of it being unintelligible.
|
| So basically, code can be both good and bad. It just requires
| that someone opens the box? Schrodinger's code.
|
| I think I'll stick with my own definition, thank you.
|
| Good code: works as expected, strives to be secure, strives to be
| bug-free, is reasonably efficient for the context it aims to be
| used in, is concerned with maintainability (this is where
| readability comes into play).
| minhducck wrote:
| 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
| IvyMike wrote:
| 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?
| frapaconi wrote:
| Can good code poop after a long day eating chickpeas? Can good
| code fly when people whisper in its ears?
| stephc_int13 wrote:
| 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 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.
| Jensson wrote:
| > the notion of a static codebase is largely a myth
|
| 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.
| slippy wrote:
| That's all well and good, but I don't endeavor to write good
| code; I endeavor to write great code!
| jiggawatts wrote:
| There's a sad corollary to this: because good code doesn't need
| to be read as often, people read bad code more and internalise
| its bad habits.
|
| 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.
| abeppu wrote:
| This 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.
| hun3 wrote:
| I think the author actually meant
|
| "Good code is rarely read _twice_. "
___________________________________________________________________
(page generated 2024-06-15 23:01 UTC)