36

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:

Community
  • 1
  • 1
Rômulo Ceccon
  • 10,081
  • 5
  • 39
  • 47

9 Answers9

63

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
  • 528,062
  • 107
  • 651
  • 834
  • 1
    If you go over 80 characters you've got another much bigger problem --- you are being overly verbose. A line width limit forces you to think better names for your variables and refactor away unnecessary scopes. – Hyena Jun 19 '20 at 09:35
21

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.
  • 42
    8 years later, with dual monitors and 1440p monitors being less than $300, all you reasons listed here are mitigated. So, I choose to break up a line at such a place which doesn't make the code unreadable. I hope you still aren't trying to get others to stick to 80 characters. – Monir Jan 25 '16 at 16:57
  • 8
    80 chars (not *lines*) was computer terminal resolution 50 years ago, it makes no sense to follow this standard today. – Oleg Mikheev Mar 22 '16 at 21:27
  • 6
    Python conventions still suggest 80 character attempt to keep the code clean and readable in a small window. Just because you have a 3000sq/ft house does not mean you should fill it with junk. If you need it to support your 5 person family - then by all means, fill it up. – cgseller Dec 15 '16 at 18:04
  • 3
    Whether you use a FHD screen or a USQFHD screen, I bet you *will* change the font size so about the same amount of text fits on all screens (except when you have a 2.21:1 cinematic editing screen or 1:1 MRI screen). (Side note: Python PEP8 actually specifies 79 instead of 80) – Mark Jeronimus Feb 07 '17 at 10:32
  • 1
    When everyone is using 4k screens will people write even longer lines? Because you have a wider monitor does not mean you should write longer lines. Some people prefer monitors in portrait mode, too. As a quick test, see if you can read this, or if you have to make your browser window smaller: http://www.pbm.com/~lindahl/brief.html – Spacen Jasset Sep 21 '18 at 15:14
  • We still have _physical_ restraints, no matter if using HiDPI monitors or not. When programming on a 12 inch laptop screen I still scale the resolution so that the actual resolution is probably something like 1400x1050 - depending on machine (I used both Macs and Dells). With DevTools panes in Chrome or lots of panes in IntelliJ it makes sense not to have more than 80-100 chars, since it would lead to scrolling vertically all the time. – oligofren Oct 04 '18 at 11:13
  • My 2 cents: reading narrow columns is faster and easier. See how SO limits width of posts, and try changing it in a web inspector to something wider, it becomes harder to read. It's just feel more natural, like reading a book. – itachi Apr 06 '23 at 11:28
7

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.

staktrace
  • 488
  • 3
  • 7
  • 1
    This is great if you or only a select few of your colleagues (whom you know also like to read code like you) are going to read the code. But if you are coding for a larger group of users, then it can be inconsiderate. – shahensha Dec 05 '20 at 04:44
5

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
  • 1,574
  • 2
  • 14
  • 19
5

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.

staktrace
  • 488
  • 3
  • 7
3

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
  • 3,104
  • 3
  • 23
  • 30
  • 15
    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 Nov 09 '08 at 17:20
  • so you're suggesting that we use GOTO statements? =) – Can Berk Güder Nov 09 '08 at 17:24
  • 1
    we will not start goto discussion here :) i will update an example – Ilya Nov 09 '08 at 17:31
  • don't worry, I'm j/k. =) – Can Berk Güder Nov 09 '08 at 17:39
  • I also find the second example much more readable. – Bogdan Nov 09 '08 at 18:03
  • 2
    I also find the second example more readable. My counter to the counter of "nest it a few more times with real code and try to read again" would be that you should try and factor those extra nests into additional small private methods. – Bane Oct 28 '14 at 13:37
3

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.

Markus Jarderot
  • 86,735
  • 21
  • 136
  • 138
1

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
  • 74,184
  • 40
  • 190
  • 334
0

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
  • 2,618
  • 19
  • 20