This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.

Anomaly ~ G. Wade Johnson Anomaly Home G. Wade Home

September 22, 2014

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.

Posted by GWade at September 22, 2014 07:48 AM. Email comments
Comments

Reading texts longer that 80 chars / line is hard. Period.

BTW: your blog, on my small screen laptop (13' MBP) has lines 150 characters long, which is twice the recommended length, and shows how little you know about the subject.

Your argument about punch cards is irrelevant.

Your whole post (and your credibility) collapses.

S.

Posted by: Stefane Fermigier at January 11, 2015 12:38 PM

Stefane,

Thanks for your comments.

I have noted over time that style-based decisions are very much dependent on personal opinion. Looking at a handful of documents immediately reachable from my desk, I see max line lengths ranging from 70-110. All of them appear quite readable.

As for the length of the lines on my blog, that's set by how wide you make the window. Sorry if it's two wide on your screen.

The punch card comment just refers back to where we got the 80-character limit, nothing more.

The point of the post was not the 80 character limit, but the relation between that and another arbitrary limit.

I'm sorry if I didn't make that clear enough.

Posted by: G. Wade at January 11, 2015 01:28 PM