If you can, use state machines, they provide a level of effective encapsulation otherwise hard to beat.
This menas ability to change specific behaviours wih very limited side effects.
Ask HN: How do you write code so it's easy to change?
51–60 of 78 posts
Re: Ask HN: How do you write code so it's easy to change?
#52In very simple terms make small pieces of untangled code. Think in terms of small lego blocks that connect and can be replaced and modified independently instead of tangled webs of logic.
Re: Ask HN: How do you write code so it's easy to change?
#53Keep it simple and don't allow any technical debt to build up. I've worked in run down legacy systems and in clean ones. The run down ones are impossible to change without breaking. The clean ones are just as easy as a green fields project.
Re: Ask HN: How do you write code so it's easy to change?
#54Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
This. The problem with unused extensibility is that it tends to get into the way of the extension that you will actually need... It's easy to extends something simple in any way. It's hard to refactor something that's complex.
This this. Very aptly put
Re: Ask HN: How do you write code so it's easy to change?
#55Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
Agreed - and note that this principle is in tension with the junior/intermediate (heck, even senior) urge to make things "easy to change" by just making everything abstract and configurable. ("See, now if we want to do it this other way in the future, we only have to flip this bit!") I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this p…
I think the core problem is that it assumes you know what part of the software will need to be changed. But you often don't so you end up with code that is too rigid in places that you need to be flexible and too flexible (i.e. complex) in places that don't need it.
Re: Ask HN: How do you write code so it's easy to change?
#56If you can, use state machines, they provide a level of effective encapsulation otherwise hard to beat. This menas ability to change specific behaviours wih very limited side effects.
In theory yes, in practice I'm not so sure: I've seen state machine implementations which were ten times more code than the few if/else/for loop needed.
Sure you can draw a pretty state machine diagram, but is the code really easier to read and maintain? I'm not sure.
Re: Ask HN: How do you write code so it's easy to change?
#57Maybe 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 name…
> 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.
Re: Ask HN: How do you write code so it's easy to change?
#58Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
100% this. Usually reviewing code of juniors one of the things that appear the most is how they try to apply patterns they read online to over abstract things that do not need to be abstracted instead of solving the business issue with the minimal code necessary.
Re: Ask HN: How do you write code so it's easy to change?
#59Maybe 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 name…
> 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.
Re: Ask HN: How do you write code so it's easy to change?
#60Comments and empathy for others and your future self. That means minimalism and lots of comments to remind yourself what you were thinking when you wrote it, who calls it, why, etc.