Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Green field software: five rules for writing maintainable code

If you're not familiar with the term green-field development the analogy works like this: the field is the project, developers are cows and poo is other people's hard to maintain code. Brown-field development is code maintenance and is so named because other developers have already pooed all over the place.

If you're lucky a few times in your career you'll get to take on a new project from scratch. That's green field development.On a smaller scale it could be a new control, web page or application feature that doesn't really depend on the existing code base.

Keeping this in mind here are five simple rules to make your code easier to live with over the long term and make the field a little less brown for those who come after you:

  1. 1) Don't write something in one line of code if two lines is more easily understood.

    Having multiple operations on a single line is a code smell; it makes code more difficult to understand and harder to debug. Given a choice between conciseness and clarity, choose clarity.


  2. 2) Name things well; rename them early and often.

    How well things are named plays a huge role in the maintainability of the code. If you find that the name of a variable, property, function or class doesn't match its purpose then rename it; the earlier you do this the easier it will be. If you find a function or class is difficult to name that's often a sign that it's not cohesive and/or needs to be refactored.


  3. 3) Avoid premature optimization.

    Optimized code tends to be less readable. Given a choice between clarity and performance, choose clarity unless speed has proven to be a problem. If speed becomes a problem identify your bottleneck, fix it and comment the optimization explaining both how and why.


  4. 4) Follow the style of the existing code where possible.

    Consistency makes code easier to understand. Teams should try to converge on a single style. As a team member let go of your preferences and emulate the status quo where possible. If the status quo sucks then work with your team fix it.


  5. 5) Keep the code as simple as possible but no simpler.

    When solving a problem in code look go for the simple solution first. Simple solutions are easily maintained and easily changed. Having explored a simple solution and understood the problem it's easier to refactor to something to more complex if necessary. In contrast novel solutions tend to be hard for others to understand and maintain... pursue those on your own time, for fun.


What about you? Are there any tips you have for writing maintainable code?

0 - What do you think?: