BPGB: A Tale of Two Lengths

As a first post in the Best Practices Gone Bad series, I figured I would take an simple example from a previous job.

An Example

In that position, there were two best practices that intersected to generate unreadable code. The first practice was expressive names. All names of variables, classes, and methods were required to be long enough to be clear and readable. In any moderately complex system, this will result in pretty long names.

The second practice was to limit all lines to 80 characters. Research into both software and web page design has shown that longer lines are harder to read. Many programmers have settled on 80 characters as the perfect line length, despite the fact that we no longer program on punch cards.

As this was a Java project, method chaining was a pretty common practice. This resulted in code that looks like:

SpecialResultClass resultOfInterestingAction
                   = businessObjectCollection.getItemByIndex(
                       theIndexOfTheObjectOfInterest
                     ).performActionReturningInternalObject()
                     .performInterestingAction();

Obviously, these are not the actual method and class names, but the length is consistent with actual code. The result is a relatively simple action has extended to five lines of code. This is not in any way clearer than code used shorter names and/or a slightly longer line length.

Result result = businessObjs.get( i ).getFoo().act();

Obviously, this is only clear if you know what the objects are. But, that observation also applies to the longer case.

The Intersection of Two Lengths

So, how did two best practices end up with code that was mostly unreadable? The problem is that the two best practices take opposite approaches to the readability problem. Since there is no one, true solution to any problem, a compromise was needed between these two approaches. Unfortunately, the people making the rules refused to compromise. The result was code that was painful to read.

Conclusion

This is a really good example of how best practices go bad. The intent was to apply best practices to improve the software. Unfortunately, the people making the rules did not foresee how these practices would interact. The result was that even simple methods became long because almost every statement took up 3-10 lines.