Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Sorry, Linus

 
Saloon Keeper
Posts: 22263
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the big tech new items of the week is Linus Torvald's War on 80 Characters.

Linus says that 80 character source code lines are obsolete and harmful. If I've got his justifications correct, they are:

1. Terminals these days are very wide and there's room for more than 80 characters to display, so why waste the space?
2. Breaking statements up over multiple lines makes them harder to read.
3. Broken lines are harder to "grep" for code.

OK, fair enough, but I have my own opinons on the matter. And my own justifications, so here goes.

I should note that I go far enough back that I have worked with punched cards. Technically IBM's primary punched-card format was 80 columns, but most programming languages reserved about 8 characters for sequence numbering (so you could, in theory run the deck through a card sorter if you dropped it and scrambled the cards). In actuality, the languages of the day often didn't stop at 72 usable columns. I think COBOL's effective line length, once the indentation was accounted for was closer to 66 columns. Shades of Python! Or maybe vice versa.

Ironically in that same era, printers were generally at least 120 columns wide and 132 characters were popular. Lower-case was extra-cost and sometimes so were characters like the underscore.

So that undoubtedly helped shape me.

I first ran into long line issues back in the late 1980s when working on Macintosh computers. Since C didn't have built-in line limits, unlike Fortran and COBOL, my co-workers were routinely coding lines that were 100 characters long or so, courtesy of the longer text display of the Mac terminal screen. Unfortunately, when I went to laser-print source code that stuff would run off the right-hand side of a US Letter-sized page using 10 or even 17 characters per inch. So this was Strike 1 against long lines. I don't print much anymore, but when I do, I need to be able to see everything in the code, not just the left-hand side of it and there's a limit to how tiny I want the print to be. Going Landscape isn't a good alternative. It's a little wider, but you have fewer lines on the printed page and nothing makes code harder to follow than random page breaks.

As it happens, yes, I have a wider monitor now, but that's not because such things were useful for good coding, it's because modern monitors were designed to display HDTV. Though any advantages that the extra width gave me for code text have largely been neutralized by other claims on real estate. HDTV monitors are wider, but they sacrificed height. And that means that the auxiliary panes of my IDE have to be on the side. I routinely have a project directory outline on the left and a source module outline on the right and frequently a few more panes and tabs as well. And that's just within the IDE window, which itself may not always own the whole screen, since these days there are so many other things to do as well. One reason I spurned Gnome 3 for Cinnamon Desktop in fact was that Gnome 3 discarded all the upper and lower toolbar applets that I depend heavily on.

So my useful editing area isn't as much wider as one might expect.

How about the complaint that breaking lines to fit 80 columns reduces readability?

Well, Which is more readable to you. This?
Or this?

Let me confess that the actual code I lifted this randomly-selected example from did in fact use the first form. But it was a hack job anyway. You can argue about where to put the breaks, but the point is that there are breaks.

In English, run-on-sentences and endless paragraphs are considered bad style because they're harder to follow. So let it be with code. Break it up into meaningful chunks. Yes, this means more potential page breaks if you actually are printing code. And more vertical scrolling. But at least when you're doing OOP, your program units are supposed to be shorter anyway. And note I said meaningful chunks. If you're breaking lines just because you finally hit the terminal margin at column 153, that's not going to make the code any more readable.

Final note: not everyone is going to have the same sized editing windows. So if 80 isn't the limit, what should it be? Actually, I have my IDE draw a warning strip at column 66, but that's just my preference.

So what about the argument about "grep-ability?"

That one's just silly. First and foremost because code with decent documentation in it should be grep-able on the documentation. Secondly, things you "grep" on would most likely be code phrases, not entire lines, and if you broke in meaningful chunks, the impairment to grep-ability would be less. Though I'll admit I've know people who had fatal coding habits that had to be located and neutralized every time and some of them might not be single-phrase.

But.

We're talking about a Unix™-like OS! What could be more Unix-like than a multi-line grep utility? It's relatively trivial to make an app that consolidates all those split lines into long lines and pipes them into standard grep. And that, after all, is Unix in a nutshell.

So that's my arguments against long lines. One final practical note, however: if you code really long lines, they're probably going to be   to run a debugger through anyway. I routinely break stuff that could be a single statement into multiple statements just because of that.

Thoughts?

Addendum. The CodeRanch Concern.

Almost forgot. While the above arguments are based purely on my own selfish wants, there's also an external reason for keeping text lines short.

If you need help and you copy-and-paste your code to a forum like the CodeRanch, we have our own framing. If a sample is too long, It won't display readably. Either it will get truncated or it will be placed in a horizontally-scrolled pane. Horizontal scrolling is much more annoying than vertical scrolling. Most of us don't have a horizontal scroll wheel on our mice, for example. Even if the text is wrapped, it's not going to get wrapped in a semantically-meaningful way.

Another concern is that once you post on the Internet for others to read, there's no guarantee that whoever reads it will be sitting at a desktop with a wide-screen monitor. Reading wide text on a tablet or phone screen is no fun at all.
 
lowercase baba
Posts: 12871
62
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Which is more readable to you.


I would argue that it all depends on what you are used to.  The brain is amazingly flexible, and can learn new skills.  If you were to practice reading one or the other over and over and over, it would become just as easy to read. (That is my personal belief - I have no scientific evidence to back that up).

Further, it doesn't matter what I want, or what I prefer. The most important thing is to follow the same coding convention that everyone else working on your project/company does. Consistency is more important.

Finally, I thought we had solved this problem by having code formatters.  I should be able to check out source code, run it through a formatter to MY preferences, and work on it like that.  Then when I check it in, it should be run through another formatter to ensure it is back in the company standard.  Granted, I've never worked anywhere that did this, and I don't know how successful that process is, but it sounds like it should work.

 
Tim Holloway
Saloon Keeper
Posts: 22263
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

fred rosenberger wrote:
Finally, I thought we had solved this problem by having code formatters.  I should be able to check out source code, run it through a formatter to MY preferences, and work on it like that.  Then when I check it in, it should be run through another formatter to ensure it is back in the company standard.  Granted, I've never worked anywhere that did this, and I don't know how successful that process is, but it sounds like it should work.



From experience, no. You end up with a lot of issues with false differences due to whitespace changes. It makes people very unhappy.

It doesn't help that formatters usually don't do quite what you'd like - and automated line-splitting is a prime example - so the actual formatted code often gets a few manual tweaks.
 
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic