> Code that is no longer being touched is not done; it's dead.
The goal should be to write code not needing maintenance.
Four weeks ago I contacted a coworker to ask about some routines he wrote 5 years ago. He said he hadn't touched them in 5 years. The code has been tested continuously in the interim. His old code worked perfectly for me the first time and it saved me hours.
No. The only code that requires no maintenance is the code you do not write. In other words, "No code is easier to maintain than no code." Add that to the nihilist coding attributes:
> ...preparing for code/components to be thrown away is a no-op.
You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.
> Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
> Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions.
I think you essentially agree on what people should do, regardless of whether you call this 'good code' or just maintainable code.
Write tests. Give things good names. Use comments to explain why you're doing something, not how to program. Don't copy and paste the same implementation x times because that way there's only one place to fix it.
> The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more importantly the less motivated anyone is in maintaining it.
The more testing that's been done and the more stable it should be.
The argument for new can be flipped because new doesn't mean better and old doesn't mean hell.
> The less code you need to solve your problem, the better.
Couldn't agree more. I always reject PRs with dead code in them. The author will argue that they added it for some future use case, but in my opinion it is never acceptable to have dead / unreachable code. It's confusing for future readers of your code and you can always add it later if your imaginary use case ever becomes real.
> Having said that, I certainly hope that this does not become some sort of thing that people spend a lot of time worrying about, enforcing, or baby sitting others.
If that is the case, then that precisely proves the usefulness of such a code.
This is the largest difference. When there's no expectation of code lasting beyond a very short lifespan, why go through the effort to future proof things, improve maintainability, have better ergonomics, etc?
All other things being equal, this is true, except for hardware issues where replacement parts may be very expensive or completely nonexistent.
reply