views:

981

answers:

11

Do you follow a standard for wrapping long lines in source code? What line length do you find most comfortable to read?

Sometimes I find people who program on wide-screen monitors and like to use its full width for displaying source code. I prefer shorter lines, around 80-100 characters, but I have a hard time trying to convince colleagues with the ever-increasing popularity of wide-screen devices.

Edit:

Similiar questions:

+1  A: 

You should not have to scroll horizontally to read the code. But larger screens does not mean longer lines! There is also a limit to how much there should go on in a single line.

So I say: Keep it at 70-80 chars just as always. Larger screens just means that the IDE as more room.

myplacedk
A: 

I program almost exclusively on a laptop, so I agree with the shorter lines. Granted, I'm usually designing screens for PDAs, so I can get away with it. But if code is shared between developers it will end up on somebody's laptop eventually, and scroll bars make me cry.

MusiGenesis
+1  A: 

I stick to the 80 lines rule (And try to convince everyone to do the same). Some reasons:

  1. You can open 2 (or more) editors at once.
  2. Same thing with compare tools. - most (all?) of them display the two(some three (some more ?)) files side by side.
  3. Sometimes you need to work from remote, on a different workstation, or a laptop, and suddenly, your nicely formatted 120 char's to line code looks horrible.
Tamir Shomer
A: 

We use coding standard of 80 characters in line. The original reason for 80 char limitation is not relevant today, but some number should be picked...

Beside the obvious (code organization and readability) usually i found that long lines are result of bad styling and folowing such rule improve code quality and reduce errors. Just compare the following examples :

status = do_something(); 
if (status == error)
{
    do_error_handling();
    return;
} 
/* do you regular flow */
status = do_more();
if (status == error)
{
    do_error_handling();
    return; 
}
/* do more of you regular flow  and keep you line 80 chars*/

instead :

status = do_something(); 
if (status == succes)
{
     /* do you regular flow */
     status = do_more();
     if (status == success)
     {
            /* do you regular flow */
            /*  nest again and get line behind visible screen */
     }
     else
     {
         /* do error handling */ 
     }

}
else
{
     /* do error handling */ 
}

Second example is much less readable hard to maintain and probably will lead to some problem on the way ...

Edit

Replaced goto with do_error_handling() in the code to avoid not relevant discussion.

As i stated before 80 characters not relevant today it's just a number 100 is good as well.

For anyone that found second example more readable please nest it few more times with real code and try read again :)

Ilya
funnily enough, i find the 2nd one much more readable, and expected that to be your example of 'readable' code when i first eyeballed your post. I've never understood this fascination with 80 chars in modern coding practises (i understand the historical significance). I usually keep it to 100chars
Karan
so you're suggesting that we use GOTO statements? =)
Can Berk Güder
we will not start goto discussion here :) i will update an example
Ilya
don't worry, I'm j/k. =)
Can Berk Güder
I also find the second example much more readable.
Bogdan
+1  A: 

Bigger screen -- Bigger font. I use GVim with Conslas 14pt maximized at 1280x800 screen resolution. I try to wrap at about 80-90% screen width.

MizardX
A: 

It also depends on other conventions that you're using. At one job, we were programming in Java and the convention was to use long and descriptive identifiers, which meant that only a couple of them could fit on a line without running into the 80-character limit. I thought that was pretty stupid considering every developer in the company was given a widescreen monitor that could easily fit 200 characters. With hardware consistency like that it makes no sense to enforce a stupidly small line wrap limit.

stak
A: 

I prefer longer lines for one simple reason: I can fit more code into my window. There is a huge difference between having to scroll vertically to read a function and being able to fit it in a single screen. If everything is line-wrapped so that the function scrolls off the bottom while the right half of my screen is empty, I consider that to be a huge waste. Note that opening two editor windows doesn't help here either.

stak
A: 

Apparently I have lines up to 258 characters in length (counting tabs as two characters) in one of my recent projects, so there's my answer. =)

Can Berk Güder
+1  A: 

Similar question at When writing code do you wrap text or not?, my answer is there... :-)

PhiLho
A: 

I use around 72-75 columns to ensure that I can print the code on letter-format pages without too much trouble. I also use spaces instead of tabs and am careful about the layout.

To notice when I am going off the right margin, I often put in a text line that I can use as a ruler. I set the IDE display window so the ruler just fits the horizontal width and then I make sure I don't go outside of it.

I do this in .txt documents as well as .c, .java, .cpp, batch files, etc. This makes it easier to send snippets in e-mail, post on blogs, put in comments, etc. The ruler is often just beneath a top line that identifies the file and the format of the text:

/* example.txt 0.00                  UTF-8                   dh:2008-11-09
*---|----1----|----2----|----3----|----4----|----5----|----6----|----7----*
*/

Of course, the comment convention of the particular kind of file is used.

orcmid
+4  A: 

Don't compromise readability for dogmatic rules on the exact number of characters in a row. Horizontal scrolling is undesirable but an 81-character line is easier to read than an indentation-confusingly line-wrapped version.

80 characters is likely to be inadaquate for programming styles with large indentations and/or verbose variable names. Keep the amount of logical complexity down to a per-line maximum, not the number of characters.

bobince