ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

Anti Coding Standards (Keep Line Lengths Under 80 characters)


We all have seen and used many coding standers in different projects based on the programming language e.g. c or java. I have been using coding standards suggested by SUN for java based projects.

I just don’t know why we still follow few coding styles suggested in the standards e.g. 80 character limits for a line, if a line exceeds 80 character, break it to the next line.

As I know the reason for this was explained below:
some terminal are not able to properly display more than 80 characters in a line and we need to scroll the editor to see the full line, so it is suggested to have max 80 character per line.

However, these days you will find most of the monitors are wide screen (most of the commercial companies uses them) and capable of handling more than 80 character per line.

I think this type of coding standards should be picked based on the projects. As an example if entire company has wide screen monitors and uses a common editor e.g. eclipse, then this rule should be reevaluated to maximize the capability of the hardware and software. This makes code much cleaner and makes it more readable.

My pet peeve is people using spaces instead of tabs. When tabs are used you can adjust their width in an editor so everyone can settle on their preferred width instead of being stuck with the authors. I find it's alway the first thing I've to change after copying a code snippet from, say, online.

P.S. I agree with you on the total line width too, 80 is needlessly small these days. Though it's still important to not go excessively long.

Yeah, 80 is a bit on the short side, but too long is bad as well - (my) reading speed decreases dramatically for über-long lines, and especially if those are mixed with short lines, which tends to be the case while coding. It also depends on what kind of code it is... often it makes sense to split long expressions into sub-expressions, and camelCasedMethodNamesCanSometimesBeWayTooLongEspeciallyIfOneMethodHasTooManyResponsibilites() - refactor!


[0] Message Index

Go to full version