Code Reduction or Spartan Programming

One of the best ways to reduce bug counts, simplify maintenance, and enhance performance is to reduce the volume of code in a project.

Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.

- Albert Einstein

Why?

Reducing Code Rot

There is a path that almost all projects take from the initial development to the dreaded (but, often welcome) re-write. Generally, as time passes in a project's lifetime, the volume, complexity, and maintenance effort grows. The re-write happens when adding/changing features becomes nearly impossible due to project complexity and the weight of maintenance. This is often referred to as Code Rot.

Complexity and maintenance effort is directly related to the volume of code. So, unless you work for these guys, one of the best ways to delay the re-write (and save money) is to keep the shear quantity to a minimum.

A culture of continuous refactoring can help bring the complexity down at the same time. This can be difficult in many places because management often has the "if it ain't broke, don't fix it" attitude. Unfortunately, in the world of software development, this attitude is a primary contributor to code rot.

How

Developers Need to Know Their Stuff

One of the best ways to reduce code volume is to simply know the standard API (for your language), and the APIs of the libraries in your project. I can't count the number of times I've seen re-implementations of methods that already exist in the Java Collections API. Let's face it, you don't have to maintain code you don't write.

A developer that knows their API well doesn't waste time re-inventing the wheel (or fixing that new wheel).

Standard Idioms

Generally, the standard development idioms are concise. They are also well understood and easily recognizable. Developers who use them will make life easier for the developers that come behind. Many IDEs have shortcuts to generate them automatically (type 'fore' and hit ctrl+space in Eclipse, it'll give you the foreach code).

Libraries

The next technique to reduce code volume is to use libraries. Care should be given with libraries (you don't want to add several megabytes just to save 3 lines of code). Some of my favorites comes from Jakarta Commons.

A common example, parsing a page number from a request (many MVC frameworks make this unnecessary) 

String rawPage = request.getParameter("page");
int page = 0;
if (rawPage != null) {
  try {
    page = Integer.parseInt(rawPage);
  } catch (NumberFormatException e) {
    page = 0;
  }
}

Using Jakarta Commons Lang, it can be replaced with: 

import org.apache.commons.lang.math.NumberUtils;
...
int page = NumberUtils.toInt(request.getParameter("page"));

Dead Paths

Over a project's lifetime, features are added and removed. Often, not all of the implementation code for a feature is removed when the feature is taken away. Over time, this decreases the signal to noise ratio in the code.

Periodically, examine the code base, look for code that may never be executed. Delete it. Don't save it for a rainy day, that's what version control is for.

A trick for finding dead paths in the code, use AOP to log paths of execution in the code. Identify un-used portions and try to verify if they are really required anymore.

You don't have to maintain code, you've deleted

Eliminate Copy-Paste

One of the worst culprits in any project is copy-paste code. It increases volume, multiplies bugs, and just creates untold problems. Use a tool like PMD to identify copy-paste code.

Better yet, integrate it with you build and continuous integration system to make copy-paste reports public. Get the entire team to buy-in to eliminating copy-paste code.

A Little More Can be Less

Sometimes a little more can result in less complex code. Take the current mantra of composition over inheritance. Composing classes that implement a common interface will create a little more code up-front. However, the reduction in complexity is well worth it. Don't believe me, just ask Google.

The maintenance effort and reduced understandability of extended classes just makes them not worth it. Often, as a code base matures, the special conditions in the extended class grow so much, that the line count savings is lost. This will happen sooner than you think.

Don't Write a Framework

One of the most common traps we developers fall into is framework creation. When the infrastructure code for a project takes on a life of it's own, it becomes a framework. When it looks like you are creating a framework, step back.

One of the big framework traps appears when an existing system doesn't have some critical feature that's needed for a project.
Solution:
Write, and submit, a patch.
Now, you've got free QA and free maintenance of that patch. It's good for your project, your company, the community, and your resume.

Minimalism

Minimalism isn't always the right choice, but it's rarely the wrong choice.

- Jeff Atwood

Beyond many of the keys above size matters. The size of your methods, the size of classes, the size of conditional blocks. The low level stuff matters.

In Jeff Atwood's Code Smaller post, he warns of the code base become a giant Katamari ball. I think we've all been involved in projects that made it into that state.

Key: don't let your code get like this:

My Path

Generally, I like the method of minimalizing to the absolute minimum, then expand the code just enough to be readable. Unfortunately, there isn't always time for this. Terse code can be hard to read but, less code is usually easier to read than more. Often in the process of minimization, unused code is discovered and ways to reduce logic are uncovered. The result: easier maintenance and simpler code.

Inspiration

Hemingway Style

One (of the few) things I remember from high-school English is the lesson on the writing style of Ernest Hemingway. He always kept things to the minimum necessary. I think in code, often less is more.

I think Hemingway's tips for writers apply very well to developers.

As developers, the code we write has three target audiences:

We should strive to serve them equally. Who knows, the future maintainer could be you.

Key Principles

If that doesn't convince you...don't forget:

References

Comments

Join the discussion on reddit.

by: Paul E Davis

copyright@2023 willcode4beer.All rights reserved

Tech Tags:

Sponsors:

About willCode4Beer