11–20 of 115 posts
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.
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.
The bad code is read a few times and refactor as soon as we get a chance.
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.
[dead]
See e.g. http://www.literateprogramming.com/
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.
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.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).
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.
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...