I mostly use C, however this question is language agnostic. Its also subjective, so I'll tag it as such.
Many individual projects set their own various coding standards, a guide to adjust your coding style. Many enforce an 80 column limit on code, i.e. don't force a dumb 80 x 25 terminal to wrap your lines in someone else's editor of choice if they are stuck with such a display, don't force them to turn off wrapping. Both private and open source projects usually have some style guidelines.
My question is, in this day and age, is that requirement more of a pest than a helper? Does anyone still login via the local console with no framebuffer and actually edit code? If so, how often and why cant you use SSH?
I help to manage a few open source projects, I was considering extending this limit to 110 columns, but I wanted to get feedback first. So, any feedback is appreciated.
I can see the need to make certain OUTPUT of programs (i.e. a --help /h display) 80 columns or less, but I really don't see the need to force people to break up code under 110 columns long into 2 lines, when its easier to read on one line.
I can also see the case for adhering to an 80 column limit if you're writing code that will be used on micro controllers that have to be serviced in the field with a god-knows-what terminal emulator.
Beyond that, what are your thoughts?
Edit:
This is not an exact duplicate. I am asking very specific questions, such as how many people are actually still using such a display. I am also not asking "what is a good column limit", I'm proposing one and hoping to gather feedback. Beyond that, I'm also citing cases where the 80 column limit is still a good idea.
I don't want a guide to my own "c-style", I'm hoping to adjust standards for several projects. If the duplicate in question had answered all of my questions, I would not have posted this one :) That will teach me to mention it next time.
Edit 2
question |= COMMUNITY_WIKI
The issue is not the output device - the issue is readability. Take a look at a printed book - these have evolved over centuries to be very readable. You will find that the page width is much less than 80 characters, probably round about 60.
80-columns makes a lot of sense in any project. It makes it much more easier to have two related file windows opened side by side. Examples: viewing diffs and .h/.cpp pairs.
While the physical limitations of green screen terminals are largely gone, it was never the best argument for limiting line length.
The best comes from the world of print: it is hard to read very long lines of text. As the lines get longer there is an increased tendency for your eyes to skip up or down a line. This is why newspapers print in columns and why books use relatively small page sizes despite this requiring more binding.
Short expressions are easier to understand; too much indentation is harder to follow.
Remember the most important consumer of the code is whomever will read the code, and he might just know where you live.
80 characters a line, is a good guideline to aim at, for the readability and ergonomic reasons already mentioned. Always defer to common sense !
Very long lines are still hard to read - it's annoying ot have to scroll across the page, but that's all. For this reason I do stick to "sensible" line lengths, but not to a hard and fast rule. 110 would seem reasonable to me, why not try it out on one project first before rolling it out to all of them?
If you sit before a Full-HD monitor then 80 characters limitations is nonsense.
Especially if you follow the good style of self-explanatory names for variables and method names you will run into the problem that you code will grow down like crazy.
80 characters maybe good for pocket books to read on the way, but not for code.
My personal opinion that the reasonable width of code is up to ~1400-1500 pixels at normal font size. After that readability goes backwards.
Source code does not appear only in 16/9 HD screens. It may be:
I hate horizontal scrollbars which prevent me from reading a portion of code as a whole.
I think it is utterly ridiculous and against general principles of usability and accessibility, which mandate that the user agent should decide how the content is displayed. The fact that most user agents are rubbish at displaying wrapped code does not mean that we should play along and split lines according to some random rule; instead, make the user agent better.
Consider, of all things, VBA code:
sSQL = "SELECT unicorns FROM "
sSQL = sSQL & "TheTableOfMythicalBeasts "
sSQL = sSQL & "WHERE horns = 1 "
sSQL = sSQL & "ORDER BY beauty DESC "
Also written as:
sSQL = "SELECT unicorns FROM " _
"TheTableOfMythicalBeasts " _
"WHERE horns = 1 " _
"ORDER BY beauty DESC "
Or just plain written as:
sSQL = "SELECT unicorns FROM TheTableOfMythicalBeasts WHERE horns = 1 ORDER BY beauty DESC "
There is massive danger of a bug occurring because I forgot a space at the end of the first or second statement, but nearly none in the single line version. The environment should figure out a sensible way to display a single statement so that it is readable; as with HTML, the content provider (coder) is usually the worst person to presume what is right for another user. I agree with coding for readability in terms of variable names and indentation, but column width is a personal preference best chosen by the recipient, as with font face/size.
& vbNewline & _
, which makes it a lot easier to notice and also makes the code easier to read, in the case of VBScript, if you need to output it for debugging purposes. Of course, VBA/VBScript are evil so under no circumstances should you /choose/ to use either nor use them to defend your practices. :P - bamccaig
I'm going to go against the grain here and say no.
Because: there is a case for and against, and a code editor should be able to wrap (well) automatically to handle both cases. Also, by manually wrapping you are eliminating what could be a massive advantage of having wide and/or multiple monitors.
Shorter lines are good for reading/understanding small chunks of code because you are reading and understanding each line. But even then, at three levels of four space indention you've lost 12 characters and you're down to 68 characters which is not much given modern symbol naming conventions.
For understanding large amounts of code, I'd say wrapping makes the code much more difficult to read. IMO ideally for reading large amounts of code, you want it to almost look like a chart/spreadsheet, or many small spreadsheets. Wrapping makes field columns overlap which is hard to read.
Consider the following wrapped assuming 68 characters:
item0->setConfiguration( image0.height(), image0.width(), image0.pixelDepth() );
item1->setConfiguration( image1.height(), image1.width(), image1.pixelDepth() );
vs
item0->setConfiguration( image0.height(), image0.width(),
image0.pixelDepth() );
item1->setConfiguration( image1.height(), image1.width(),
image1.pixelDepth() );
I really believe that the deciding factor is that it should be fairly easy for code editors to include a feature that has wrapping rules.
You definitely don't me started on tab vs spaces...
Yes, it's still useful. For reading code, I prefer to have a wide-screen pivoted by 90°, and everything > 80-90 lines of code becomes unreadable then. So you should keep this in mind. Moreover, I've seen already quite a few people with a dual-screen setup where they have one large screen and a smaller one next to it, tilted by 90° -- this setup is not as unpopular as one might think.
The other thing is printing code, not that you would do it often, but for debugging some more serious problems it can be really useful.
In Python you are more or less forced to use the 80 characters limit - if you want to develop software like Python itself or frameworks (e.g. Django).
Python Enhancement Proposal number 8 [1] (PEP-8), "Style Guide for Python Code" says:
Limit all lines to a maximum of 79 characters.
It mentions the side-by-side windows argument.
I am using a little less, 77 characters, no matter the language: Perl, C++, C#, VB.NET, Python. One reason is to be able to use a large font without the need to scroll.
[1] http://www.python.org/dev/peps/pep-0008/I miss good old 80-char line length limit [1] every time I do code review...
Yeah I have two large displays. Yeah I can stretch the diff tool window on both displays so that I can see 2x120 or even 2x160 diff. But somehow, it still sucks. Just sucks.
[1] http://www.oracle.com/technetwork/java/codeconventions-136091.html#313Unless you're stuck with a console that limits you, I think 80 is outdated. (That number originated with punch cards!) Even with a console, you can probably set it to 132, the next standard terminal size.
With Visual Studio, I've decided to use 142. When printing code in landscape orientation with line numbers visible, that's how many columns VS prints on an 8.5x11 piece of paper without wrapping. (I use 10pt Consolas - I don't know if font size applies to printing.) With tool panes open on both sides of VS with a 1680-pixel screen, I can see 150 columns of code, so 142 works well there.
Using the Productivity Power Tools [1] extension for Visual Studio, I set guidelines at 80, 132, and 142. (Note that the "Col ##" indicator in the lower-right of VS is 1-based, so to set a guideline at 132, put the cursor where the indicator says 133.)
I'll aim for 132, let it slide to 142, and if there's a choice between readability and column limit, readability wins. I only use the 80-column guideline for CSS, but even then, image URLs that exceed the limit can't be wrapped.
[1] http://visualstudiogallery.msdn.microsoft.com/en-us/d0d33361-18e2-46c0-8ff2-4adea1e34fef80 columns started with typesetting and printing. It has nothing to do with resolution of screens or screen size. 80 columns is based on the function of the human eye and readability. Much beyond 80 columns and the eye tends to not follow on one line but drop to the next, especially in blocks of text.
It completely depends on the monitor you use. We have a 100 column standard. Which works great for our monitors.
You could argue if longer lines add any significant value. But you must not forget that this enables the use of longer (most of the time more descriptive) identifier lengths.
The main argument for the 80 column standard is readability. But I don't agree that shorter lines necessarily make code more readable if you read code on a screen. Printing code on paper (does anybody do this to any extent anymore?) is a completely different discussion.
I've seen unwanted behavior among programmers that want to cram full statements on single lines, in order to get nice predictable indentation. Giving variables extremely short names is only one example. I'd prefer giving programmers larger freedom when it comes to the number of columns if they instead use descriptive naming.
Another common argument is that short expressions are easier to understand, but that does not necessarily imply short lines. That is rather because the expression is simple.
If I had to set a limitation I would be quite generous and try to encourage other readability features also.
If nothing else, if your line of code is longer than 80 characters, something is probably wrong.
Terminals notwithstanding, that's not terse code and as such it's neither quickly legible nor properly maintainable.
I don't think readability has to do only with length/visibility of statements, but as much about program flow. Isn't it easier to read a program when lines are tightly stacked? Usually I care more what the program flow is than each individual statement. Most source files are longer than the screen, so the case could be made to use multiple statements on each line to fit as much program as possible on screen. However as someone mentioned, the editor could right-align wrapped text in case someone really needs to see the end of the line.
I prefer tight code in a small type, on black background, and when printed it should be possible to fit more than eighty chars on a line, and more than one function on each page. Often the most proper formatting contains the least readable code. I use by two-space indents, wide/multiple statements on a line, BLACK background so help me GOD (incredible how white bg survived the crt). If people are so stingy on screen real-estate, how come every developing environment is filled with sidebars, icons and stuff, and every file manager gui uses big icons, big fonts, side panes, alternating grey/white lines, multiple useless toolbars?
Oh, and unix style curly braces. They save me lines.
Its probably best to be pragmatic and only enforce an 80 column limit if it makes sense to do so...ie if a significant number of people need it to be at that limit. These days with large monitor sizes I don't think we need to be pedantic about 80 columns unless there was a specific need for it.
I think that the fact that we are now using fonts that are sizeable (albeit more often than not fixed-width) have made the 80 column limit irrelevant.
Not only that, but certain code readability standards will suffer from such limits, e.g., naming conventions wherein method names that fully describe what the method is doing without any sort of abbreviation (think AssignNumberToCustomerAndSetOrderStatus
) eats up 80 characters quite fast.
Column width is still relevant, of course, to terminal-based languages such as COBOL, but other than in that case I can't think of enough reason to stick to the 80 character limit.
I've always done 80 (header files) or 100 (source files) when I was developing in C and C++.
For some reason, with C# I tend to need more space, therefore for now I have settled to 120 columns.
In C#, Java and other recent languages, which have additional name-space, class and other overhead indentations, 100 columns (+/- 10) seem to fit well with 4 space indentation levels. Considering this on a wide screen with a 1440x900 or greater resolution, using a development environment with a sidebar permanently open.
In traditional functional languages, like C, which may be developed on an environment with a smaller screen, 80 columns provide enough width for comfortable code writing while at the same time avoiding horizontal scrolling on the more limited environments.
I code for readability. You can't read what you can't see. An 80 column limit is a little strict unless you're dealing with a language / platform that won't handle it. Last I checked, IBM's FORTRAN languages were still enforcing 72 columns. Admittedly it has been a while, but they didn't change their methods in the 20+ years I dealt with them. I don't expect them to change in the last few.
Better this way (notice where is the comma) In this way anybody who read the code quickly understands that the line is another parameter of the function above.
item0->setConfiguration( image0.height(), image0.width()
, image0.pixelDepth() );
item1->setConfiguration( image1.height(), image1.width()
, image1.pixelDepth() );
In C codes the main information is within the first characters and a quick reading does not have to read whole sentences to understand what the code is doing. For example, if it is function call doSomething(… the rest are parameters with relative less importance ); The important thing is that is going to do something, we usually do no deep into the parameters unless we have to.
I disagree with the argument that limiting the length to 80 characters makes the code easier to read, because we do not read codes. Most of the time, we make quick looks moving the scroll up and down searching for pieces of codes that do a particular task or trying to have a general understanding of what a piece of code does without get confused on the details. A code is not a newspaper, neither a book; we do not have to read whole sentences, because in any decent code have thousands of lines, and details are overwhelming.
The only reasonable reason why a code would be limited to 80 characters is for printing and show the code in web pages. But there is a danger on that, because people tend to use acronyms and short names in order to fit in one line. The most frustrated codes are those like this:
it->sCon( im0.h(), im0.w(), im0.px() );
instead of
item0->setConfiguration( image0.height(), image0.width()
, image0.pixelDepth() );
OK, I know this is a very subjective matter, but I think that the argument "readability" for 80 columns is quite debatable. I think the code becomes quite unreadable if it is chopped up every 10-60 characters (because that's what usually happens when you have descriptive variable names).
I believe humans are far more used to reading from left to right (or right to left depending on where you live for that matter) rather left-right DOWN left right DOWN left right and so on. I find it actually very hard to read code being chopped up like that and I think it is also aesthetically plain ugly.
By this, I don't mean we should write horribly wrong lines, one should use common sense of course. It should be discussed in each project, bring it up as early as possible to avoid hard discussions later. Personally I say, use tools and editor that has evolved beyond the 1980s and 1990s. Sticking to handicapped tools for some nostalgic reason is just not good enough.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
.......... As you can see, SO on my browser wraps comments at ~80 characters. :) - muntoo