Skip to content

Comment on Ask HN: How do you write code so it's easy to change?

Comments

Maybe a better question is this: how do you write code that does the most possible to prevent a maintainer from screwing it up?

It sounds like the same thing, but acknowledging that mistakes happen no matter what and trying to focus on preventing them is something much more tractable that trying to come up with the perfect thing that can be understood right away.

For instance, I used to be a fan of long variable names that say exactly what they do. I still am, but only in certain situations. In fact, I'd argue that using very descriptive variable names in the wrong situations can actually make the code less maintainable, not more.

This takes us naturally to a discussion about what works, why it works, and under which circumstances it might not work (or actually hurt), which is probably a much more productive conversation than something along the lines of "how do you guys think the best way to code is?"

Maybe a better question is this: how do you write code that does the most possible to prevent a maintainer from screwing it up?

By writing tests, that's the only way.. I remember recently writing the test two weeks after I added the feature, the feature was already broken!

The difficulty is that maintainers are very creative in their way to break your code so it's difficult to write 'thorough' tests.

Yeah. That would be my answer if I had to pick just one. Tests should give you immediate feedback if you're wrong. They might not tell you exactly what to do. I think there's a bit more to the story than just tests, or I wouldn't have been so elliptical in my comment.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.