Some reports will highlight lines of code as a figure to attach some relevance to, and these become measures used to establish progress.
These are possibly the most misleading figures to use, in fact almost always within a well designed application and code base, the reverse is true.
Good code tends to be more concise than poor code, and therefore it is less lines of code.
Good code also tends to have high levels of code reuse; one of the primary refactoring exercises is removing code duplication. This obviously again leads to a lower number of lines of code. However, the concept of reuse can also be used to increase lines of code and reduce quality in the hands of inexperienced developers.
An example:
The following pieces of code are all functionally identical:
Version One (4 lines):
public void MyMethod()
{
if (myObject == null) doSomething();
}
Version Two (8 lines):
public void MyMethod()
{
if (Assert(myObject)) doSomething();
}
public bool Assert(object theObject)
{
return theObject == null;
}
Version Three (8 lines of code):
public void MyMethod()
{
if (Assert(myObject))
{
doSomething();
}
}
public bool Assert(object theObject)
{
bool theResult = (theObject==null);
return theResult;
}
Version Four (20 lines of code):
public void MyMethod()
{
if (Assert(myObject))
{
doSomething();
}
}
public bool Assert(object theObject)
{
bool theResult;
if (theObject==null)
{
theResult = true;
}
else
{
theResult = false;
}
return theResult;=
}
As it turns out, the version of that code with the highest quality is Version One, coming in at 4 lines of code total, and actually only 1 line of code that does anything. Version Four has 5 times the number of lines of code as a base guideline, but has 8 times the lines of code if only actual statements are counted. Version Four is coincidentally the poorest quality version of the functionality.
So if lines of code are a measure of progress, a developer can, consciously or subconsciously, increase their visible progress, by writing lower quality and less maintainable code.
How About Measuring Decreasing Lines of Code as Success?
Depending on how you are measuring lines of code, even looking for trends in reduction of lines of code can be considered the wrong approach. For example, now if I concatenate multiple statements into a single terse, unreadable and un-maintainable statement, I can reduce my line count.
An example:
Version One (8 lines):
public int MyMethod(string myString, int result)
{
private int const SmallIncrease = 1;
private int const LargeIncrease = 2;
if (string.IsNullOrEmpty(myString))
result = result + SmallIncrease;
else
result = result + LargeIncrease;
return result;
}
Version Two (4 lines):
public int MyMethod(string myString, int result)
{
return string.IsNullOrEmpty(myString) ? result+1 result+2;
}
In this example, Version One of the code is simpler to read, but is twice as many lines of code. This is also a very simple example; a more complex example would be even more drastic in the difference between the numbers of lines of code in the two methods.
Within this simple example the first is much easier to read, understand, and therefore maintain. The second obfuscates the values of 1 and 2 in the calculation, and makes it harder to follow the execution path of the code.
Arguably Version Two could be considered acceptable with some modifications (like the addition of the constants defined in Version One), however both of these piece of code will actually compile to identical binary code.
In this case Version One is higher quality code as it is easier to understand its intention, and the ability to quickly read and understand intent is a major factor in determining the quality of code.
Posted
05-16-2008 9:51 AM
by
Jak Charlton