Clever code is Hard to Maintain... and Maintenance is Everything

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
Line 59: Line 59:
**Malbolge - A public domain esoteric programming language named after the eighth circle of hell in Dante’s Inferno, the Malebolge.
**Malbolge - A public domain esoteric programming language named after the eighth circle of hell in Dante’s Inferno, the Malebolge.
 +
 +
[RMH: No changes made to this one, but I'm not sure if this is really a project management axiom or a programming axiom. ]

Revision as of 12:36, 11 May 2009

Clever Code is Hard to Maintain

David Wood Fredericksburg, Virginia, USA

Which code fragment would you rather maintain, or review?

This one?

	char stringToChar(String s) {
		short i = Short.parseShort(s.substring(2, s.length()), 16);
		return (char)i;
	}

	public String sayHello () {
		String[] input = {"48", "65", "6C", "6C", "6F", "2C", "20", "57", "6F", "72", "6C", "64"};
		String output = "";
		Iterator i = Arrays.asList(input).iterator();
		while(i.hasNext()) {
			output += stringToChar("\\u00" + i.next());
		}
		return output;	
	}

or this one?

	public String sayHello () {
    	        String output = new String("Hello, World");
	        return output;
	}

Naturally, I am not proposing hard-coding values into code. Accept this toy example for what it is.

The first code fragment may not be particularly clever, but it is certainly obfuscated, makes use of relatively esoteric language features (such as the conversion of a hexidecimal number to an alphanumeric character), contains unnecessary cruft* (such as the insertion and subsequent deletion of "\\u") and will take any programmer some time to see what it does.

The second code fragment might seem boring, uninteresting or even suggest a lack of skill, but the two fragments do the same thing. Being too clever makes it hard on those who follow you. If later developers can't read your code, how do you expect them to maintain it? Any given programmer may try to be clever to enhance their job security, but no project manager will benefit from it.

Choice of language can matter, too, but only if you go to extremes. After all, the same "Hello, World" output can be obtained from this program in the intentionally difficult Malbolge** language:

(=<`:9876Z4321UT.-Q+*)M'&%$H"!~}|Bzy?=|{z]KwZY44Eq0/{mlk**hKs_dG5[m_BA{?-Y;;Vb'rR5431M}/.zHGwEDCBA@98\6543W10/.R,+O<

Switching between languages that can trace their tortured lineages back to C (or any other common way of doing things) is probably going to be relatively painless.

A software system must be replaced when it cannot be maintained. Replacement often requires reverse engineering of the original and modified requirements before a new system may be designed. Reverse engineering becomes necessary because the code and the information about the code have diverged to a degree that the best documentation for the system is the code itself. This is called a "loss of coupling" between the software components and system metadata. Maintenance failure occurs as a direct result of:

  • programmers creating new bugs via “bad fix injection”,
  • breaking the documentation by failing to keep it up to date, and
  • failing to migrate away from aging or removed system dependencies.

Code that is too clever will be misunderstood and will result in all three of the above problems. Misunderstood code leads proximately to maintenance failure.


  • Cruft - Computing jargon for “code, data, or software of poor quality. Also, any accumulation of obsolete, redundant, irrelevant, or unnecessary information, especially code.
    • Malbolge - A public domain esoteric programming language named after the eighth circle of hell in Dante’s Inferno, the Malebolge.

[RMH: No changes made to this one, but I'm not sure if this is really a project management axiom or a programming axiom. ]

Personal tools