Maintainable Software

I’m not the most minimalist person in real life: I always have a ton of things going on, be it gardening, cooking, crafting or coding projects. This is a pretty common plight for a programmer since we like to tinker. But when I code something for production and not as a toy project, I believe that minimalist is something important to keep in mind. This way, my code is simpler and easier to maintain for me and for other people.

There are many aspects to minimalist in a software project, from your technology choices from the start to good coding practices when the project is ongoing.

Keeping you code simple

The number one priority is readability and easy of maintenance, by you and by others. Trying to reduce the length of variables names or function names at all costs gets in the way of being understood. You want to keep a reasonable length so the names are clear while still being able to fit a line of code on the screen. Another good thing is to use a common coding standard for all the code on a project: there is no one true coding standard, but it’s easier to understand code without distractions when it all looks similar. In doubt, you can just use the same standard as the library or framework you are using.

Also, you want to eliminate pointless complexities in your code. First, all the code in your codebase should be actually used. Don’t code things just in case they may be needed. It just adds more moving parts that needs to be maintained, and when the case you coded it for finally happens, you’ll most likely find out that what you need is a bit different than what you implemented anyway. Following the same ideas, parts that are no longer needed should be removed, not just commented or left lying around. You can always retrieve the code you removed using source control if you ever need it again.

Finally, keep the things you are doing simple, for example, don’t use CSS selectors from hell if you could simply add a meaningful class to your markup instead. Also, useless conditions should be eliminated: if doing a piece of logic every since time has not negative consequences and has a negligible performance cost, you can do it all the time. It may even be faster to just run the code instead of checking a condition! Also, you can use returns to leave methods as early as possible to reduce the levels of indentation and make code easier to read.

Using libraries

If your goal is maintainability, you can’t always go with the shiny new toy: something new is always a risk, and you don’t want to spend a lot of time with it if it’s going to be dropped in a few months. So, when I create a new project, I aim to start with as little components and tools I can get away with. The simplest code that is closest to the HTML/CSS/JavaScript standards are always the best for long-term maintainability.

For example, for a ASP.NET MVC web application, even the default template is pretty bloated: the ASP.NET MVC framework itself (and the dependencies like the Entity Framework), jQuery and a good control library like jQuery UI is more than enough. Any additional library that you add have a cost: they will need to be maintained and updated, and you have to keep yourself up to date with all the new upgrades. If you are not using the library at the moment or only a tiny part, it’s a lot of noise to sort through while you could be doing something that moves the project forward.

Don’t get me wrong, I’m not anti-library: I don’t believe in reinventing the wheel, and if a part of my application has special requirements not covered by the .NET framework, I’ll gladly use a library that implements it. For me, a good library to use is one that does the job it needs to and not a few dozen other things, has good documentation and is regularly upgraded and maintained. It also should not take over my architecture by forcing me to use complicated patterns and by pulling along any other dependencies.

Separating concerns

I’m not a testing wizard, but there are many things you can do to help yourself start on the right foot even before you start writing that first unit test. First, you should have a simple but clean architecture, separating the business logic in the model, the controllers getting the data and the views handling the display logic. The truth about the business logic should be kept in one place in your architecture so it is easier to modify it. For performance and usability, you can add a few validations to the client-side JavaScript, but the server-side code saving the data should always has the last word. A validation that’s on the client can always be bypassed anyway, so you should never trust something sent to the server by the browser.

Also, on a lower level, you should make it clear what are the responsibilities of each class and method is doing and document each of them properly, including all the edge cases. I don’t believe in zero comments: the documentation is there to explain why you are doing something and how to use that method, not just to repeat details about the inner working of the method. A method should do only one thing: if it gets too big, it’s going to be hard to know what are all the possible code paths. Nice and small methods or views with clear responsibilities are easier to reuse in your code, and don’t need as many new tests since it’s known code.