Tuesday Mar 11, 2008

80 Column Blues

There's generally a lot of disagreement about the best way to format code. One way to make every coding style unreadable is to enforce or require an 80 column/character line limit. A lot of coding standards still include an 80 character line length limit, including the Coding Conventions for the Java Programming Language. I've also seen 72 and 77 character line length limits in other coding standards. An 80 character line limit may have been a necessity in 1968, made good sense in 1978, was probably useful in 1988 and possibly helpful in 1998 but it's definitely annoying in 2008.

Left to my own devices I find that for block comments I write to about 100 characters per line which seems to be about the same line length as a typeset book, ie. a comfortable reading length. For code my average line length, not considering leading whitespace is probably 40 characters or less, again a comfortably short reading length. With whitespace my average line of code generally ends some where between column 65 and 75. Using inner classes and other constructs can result in deeply nested braces producing 60 or more characters of initial whitespace. This is where 80 character line limits really make thinks look ugly. I've seen code that has been "de-intended" (leading whitespace was removed) and still had less than 30 non-whitespace characters per line. The result was nearly unreadable.

In my own code I occasionally write lines with more than 80 non-whitespace characters. These are commonly logging, method calls, and statements using my friend, "?", the infamous "Riddler" conditional operator. Even though these statements are longer they generally aren't too difficult to parse and I don't find the extended line length a problem.

My current conclusions are:

  • Except for cro-magnon freaks we all have text editors that can easily edit text that's wider than 80 columns.
  • Forced line breaks to meet width requirements don't make code more readable. Forced line breaks often reduce readability.
  • 80 column hard limits should be dropped from modern coding standards
  • For block non-code text the width used should be a comfortable reading width. Really long lines of text are hard to read.
  • Consideration of maximum acceptable line length should ignore any leading whitespace. The intelligibility, or lack thereof, of a line of code is not strongly tied to the total line length but to the number of non-whitespace characters in the line.
  • The readability of a line of code is probably related to the density of the syntax. Lines using only simple syntax or syntax that can be easily decomposed can be longer and remain readable.

Wednesday Jul 12, 2006

The Register Publishes Thoughtful Article

I guess it's not really news. Honestly, I love The Register though "credible", "insightful" or "balanced" aren't always the first words to come to mind when thinking of how to describe The Reg. The punchy style and entertainment value alone usually more than makes up for the lack of accuracy though.

The article referenced in the title is entirely a different story. Following blog links often leads to gold. I believe I was about a dozen links deep from I don't even remember where when I came across a link to this recent article from The Register's developer site, Long argument lists - who needs 'em?. I found the article very thoughtful and it has really clarified some of my own agruments regarding API design arguments (or more accurately, given me ammunition for responding to criticism) and it has confirmed the gripes I have about other people's APIs.

Monday Jun 28, 2004

I Lost My Source Code...

A few days ago I was working on a gnarly problem with a component in a large application. Debugging the problem was made doubly difficult because I didn't originally write the component and I don't have the source for the component.

Well, I sort of have the source code. I have version of the source which is close to the version the compiled version that's been used for a couple of years. I don't have a changelog between the two and I don't even know if the source archive was created before or after the compiled version! It's a pretty frustrating situation.

Why is it that some developers continue to deliver software built with less care and attention than most people would use in making a sandwich? Worse yet is when whole teams or organizations engage in this poor behaviour. You'd think that at least one person would stand up and say "This is madness!" Sometimes the poor practices continue for years and years before the team eventually fails. Inevitably the reasons for the failure are never understood by the participants but they are left burned out and frustrated.

My experiences with most teams in Sun has been pretty good. Sun teams seem to generally be somewhere around SEI CMM Level 3. There are some teams at Sun which perform even higher. This is much better than the industry average and it's one of the reasons why I like working at Sun.

The most disappointing part of modern software engineering is that it seems to be taking forever for the standard practice to improve. I keep expecting that there is going to backlash against the software industry as a whole for shoddy development practices. Maybe it's already happened though. The custom software market has dwindled in recent years. Perhaps it's because the customers realized they were getting poor value for their money in most cases.

A lot of the problem is cultural. Know a developer that eschews testing? Has disdain for version control? Contempt for process? Ridicules documentation? It's time to start treating them like the crackpots and outcasts they should be. Perhaps a few software van Goghs might be lost, but would you really want him painting your house anyway? The idea of a brilliant but inscrutible programmer is pretty much a myth anyway. If you think of the people who have been recognized for making significant contributions to the software industry are they not all fairly well spoken and articulate communicators or at least understand the value of communicating their ideas? Grace Hopper, Larry Wall, Linus Torvalds, Bill Joy, Tim Berners-Lee, etc.

Extreme Programming has been helping a lot to improve the culture of software development. I certainly hope it continues to have positive effects. Lost source code may one day be a thing of the past.




« April 2014