Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 78 posts

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

#41

Post by simion314 »

My strategy is make small functions that do one thing then combine this small functions to create larger ones. When a new requirement is added to change the large functions you probably have to change just one or a few of the small functions but many of the smaller functions are unchanged. Also when this new requirements are added you can reuse the smaller functions, most issues I had to fix is understanding code that evolved over time and ended up to be a giant function that does too many things , with many branches.

Also make the code easy to read and understand, have good naming convention for the small functions and variables, add comments if you have to do something unusual (like workarounds for weird quirks or bugs) so it makes sense 3 months later when you read the code again and you forgot most of it.

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

#42

Post by DanielBMarkham »

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?"

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

#43

Post by jrockway »

Less code, loose coupling. Do one thing and do it well. Keep the external API simple.

It's always easier to change a small thing instead of a large thing. So make a small thing, and only make it a big thing if you absolutely have to.

I think my favorite recent HN example of this was that article where Discord rewrote their "unread message count" service in Rust. They were able to make a huge change to a critical section slowly and incrementally because it was loosely coupled. The programming language they chose didn't matter, because it could just be changed. The implementation didn't matter because the consuming code didn't know about any implementation details. The change happened and all the other teams had to care about was that there weren't weird latency spikes anymore.

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

#45

Post by btilly »

Factor out logical units early and often.

DO NOT try to generalize and abstract until the third time that you are writing something. (Having written it for other companies counts.) Until the third time your guesses about the right generalizations and abstractions generally work out badly.

Focus on simple over clever. I cannot count how many abstract systems that I have seen which were designed to achieve some general purpose reusability. They almost never actually achieve the asked for dream and almost always become a barrier to comprehension by other developers.

FOLLOW ALL STANDARDS IN YOUR ORGANIZATION. Code review. Unit tests. Formatting. Naming conventions. Doing what you think is the perfect thing is almost always worse than staying consistent with other developers.

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

#46

Post by jmilloy »

In codebases I've worked on, the biggest culprits that make maintenance and modification difficult are

- functions that do several different things

- tight coupling

- implicit behavior

- too much indirection

- too many thin custom wrappers

Often several of these come together when an inexperienced developer factors out everything they can (over-eager DRY) but still tries to keep a few highly specific things "easy". One thing I see often is modules or classes that wrap a standard library, adding code essentially removing features in the interest of "ease-of-use".

I think you can write better code if you write code in multiple passes: only write what you need right now, and use the code as-is between each pass. With that approach, you'll gain some real intuition about what is easy to read and modify, which is much more helpful than someone's list of tips.

That said, I've found that writing simple explicit functions that take arguments and return a result can get you pretty far. Same for class constructors and methods, API endpoints, etc. Try to avoid writing "convenience" functions or classes when just using the library directly with some arguments would suffice. In other words, boilerplate probably isn't as bad as you think, and the indirection/implicit behavior/tight coupling is often worse than the boilerplate.

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

#47

Post by thdrdt »

Easy to change code is code you understand a year later.

This includes:

Easy to understand variable and function names. IDEs make autocompletion possible so don't fear long names. MyEasyToUnderstandFunction() is better than MyETUF().

Function names should describe what they do. CreateOrder() is better than NewOrder().

Make sure you don't use global/public state in any object or component. Public state is one of the biggest sources of failure and bugs. If you can, don't use it.

KISS: Keep It Simple Superstar!

But maybe the most important (for me): use separation of concern and context. This always helped me a lot. For example: if an email must be sent when a new order is created you can put the email code directly after the order creation code. This will ofcourse work and might even be valid code. But the component that creates the order should not be bothered with how emails must be sent. If you separate this, it will help you a lot to create maintainable code.

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

#48

Post by jressey »

Think of your tests as a consumer of the software you create. You will know it's easy to test if your component does not take much setup. If you have to create all kinds of different objects to get a test to pass, you've built a coupled component.

Said another way: Making an easy to understand interface to your software should be your top priority. Make the interfaces within your public interface as easy to understand, etc., all the way down.

Easy to test: Easy to understand. That makes it easy to change.

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

#49

Post by contingencies »

Documentation (document the "why"). Loose coupling (this goes for databases, programming libraries, languages and paradigms, and operating systems as well as function interfaces). Design data structures first. Make everything a program. Make every program a filter.

Those who don't understand Unix are condemned to reinvent it, poorly. - Henry Spencer

Many architecture tips here: https://github.com/globalcitizen/taoup

Post reply on HN