Writing Maintainable Code - You’re Doing it Wrong

May 22, 2015
by
Matt Dixon

How many times have we seen this? A project where nothing is documented, there are no unit tests, and it is a miracle the software even runs let alone works properly. This is most projects, but it doesn’t have to be.

The Problem

The problem is pretty simple; the code is a nightmare.

Long Methods (Cyclomatic Complexity)

Pet peeve number 1. Your methods should fit on a screen. Period.

Cyclomatic Complexity is a computer science term used to
describe the number of paths through a particular piece of code. The lower the number, the fewer paths through that code. Visual Studio 2013 has code metrics built right in. No more excuses. Here is a good example of how it is calculated. The basic principle is that the software should have as few decision points as possible while still accomplishing its intended purpose. There is a lot to be gleaned from providing a simple
solution to a complex problem.

If the Cyclomatic Complexity is high, the code is not very maintainable. Providing small methods within your class will ultimately reduce the Cyclomatic Complexity and require the developer to think about how the method is used. Keeping methods small
will ensure they only do one thing, and that they have lower Cyclomatic Complexity.

DRY Principle

I worked on a code base we inherited from another team and we called it “Notepad Inheritance”. As we all know, the DRY Principle is
“Don’t Repeat Yourself”. If a piece of code has been written twice, it’s time to extract that to a method. C# has Extension Methods which are great for methods against a particular object type. There is no excuse now.

Code Smell

Guests, like fish, begin to smell after three days.

- Benjamin Franklin

Code, like guests or fish, may also start to stink. Code Smell is a great way to describe that something isn’t quite right, but we don’t exactly
know what the problem is. It is an indicator to start looking for refactoring opportunities.

The Solution

The solution is just as simple as the problem. Clean up your code, and then you can go outside and play. While none of these items guarantee clean code, skipping them guarantees a mess.

Build It Into The Schedule

When everything is an emergency, nothing is important.

Code Reviews

Code Reviews are invaluable in software development. Every developer can provide some excellent ideas. The best use of code reviews I have seen
was on a project where a Code Review was part of the Definition of Done. If a story was deemed as complex enough to warrant a code review, a code
review task was created and had to be complete before the story could be signed off.

Unit Tests

If you would like to see the true state of your codebase, try adding unit tests. it will become painfully apparent the architecture, or lack thereof. In order to test certain features, it will probably require some refactoring. Moving forward with unit
tests becomes much easier once those changes have been made. Teams have also included a minimum of 80% code coverage on new development moving forward.