PDA

View Full Version : Programming standards and line length



r-senior
April 11th, 2011, 03:49 PM
This is just out of personal interest really, not an official poll or research, even though I've made it sound like one ;)


Does you find people/places still adhere to the old 80-column rule?
Does it depend on which language is in use?
Have you adopted, or been asked to adopt, a different standard, e.g. 132?

VernonA
April 11th, 2011, 04:24 PM
At my company it's an informal rule, ie we try to keep lines below 80, and if a line needs to be broken we try to place the split so both results are under 80. However we don't insist on the rule, because some lines just don't split well. We like variable names which are self-documenting, so sometimes they get a bit long. If this forces a line to be say 90 or even 100 chars long so be it.

johnl
April 11th, 2011, 05:01 PM
This is just out of personal interest really, not an official poll or research, even though I've made it sound like one ;)


Does you find people/places still adhere to the old 80-column rule?
Does it depend on which language is in use?
Have you adopted, or been asked to adopt, a different standard, e.g. 132?


Everywhere I have worked has adhered (in various degrees of strictness) to the 80 column limit. It seems to me that lines longer than 80 characters tend to get to be difficult to read anyway; splitting them up cleanly can improve readability.

I have noticed that it is usually a lot easier to split lines in certain languages (e.g C) than in others (Python). That's just my feeling, no hard research of experience.

slavik
April 11th, 2011, 05:18 PM
when first programmers for actual computers appeared, they used punch cards. those punch cards had 80 columns. this later gave rise to terminals that displayed at most 80 characters on one screen.

Reiger
April 11th, 2011, 07:10 PM
But the reason it is kept has to do with the fact that 80 columns is also a comfortable line length for Western scripts.

schauerlich
April 11th, 2011, 07:22 PM
Try writing a Cocoa app with a 80 character line limit.

simeon87
April 11th, 2011, 07:39 PM
Although its origins can be traced back to technical limitations, I still prefer to keep my lines at 80 chars for readability. It helps to keep the code clean and readable.

Simian Man
April 11th, 2011, 07:52 PM
I never break long lines into two lines like:


if((something really really long) && (something else really really long)) {
-----------------------------------------------------------------------
if((something really really long) &&
(something else really really long)) {


Because I think that looks really hideous. I do break things logically sometimes like:


cond1 = something really really long;
cond2 = something else really really long;
if(cond1 && cond2) {

But I just do this when things get too messy, not when I have surpassed some arbitrary limit.

1clue
April 11th, 2011, 07:52 PM
At work we use a "soft" limit of 140 characters.

Everyone who programs there has at least one 1920xsomething monitor, so this leaves plenty of room on the side for other IDE panels.

We find that code where the command wraps is more difficult to read, so we go extra wide. The limit is "soft" because if some command is only a few characters longer, or if it's for some reason more difficult to read wrapped, then we can go with a longer line.

Most of the time lines are under 120, or in some cases the complexity of the line becomes more easily read in multiple lines. For example, I often brake an if statement up:

if(someFunction(this.that.theOther)
|| someOtherFunction(foo.bar())
|| ...) {

Sometimes the logic gets pretty complex, perhaps nesting logic within logic, and it gets hard to figure things out without breaking the line down.

The one overriding rule for us is ease of readability. If the line is just some huge call with a bunch of options in it nobody will be interested in, we extend it out. If the call can be broken up and be more readable, then we break it up.

cgroza
April 11th, 2011, 10:59 PM
I really like them at 80, if they are longer, it starts being a problem on my monitor because my IDE is kind of bulky and takes up a lot of room.

aport
April 13th, 2011, 09:37 PM
There is a quote, I'm going to butcher this, which is basically, "Programs are meant for reading, and only incidentally run on a computer."

Reading very long lines of code left to right can be a bit frustrating. Splitting these lines to fit within a set column limit (most commonly 80) improves the readability of code a good deal.

The Linux kernel style guidelines, which is my Bible in terms of programming style (at least in C), requires 80 columns maximum. Gedit has an option to show the margin at 80 columns default, and it's a good rule of thumb.

The Linux kernel style guidelines go one step further, and assert that if your code considerably overruns 80 columns, due to excessive levels of indentation from nesting or really long function and variable names, then you should perhaps re-think your programming strategy. I tend to agree with this. At least in C, there is really no good reason for your code to go past 80 columns. I've read tens of thousands of lines of code in C and have never seen a good justifiable reason for exceeding 80 columns. The programmer may think he has a good reason, but another programmer will be able to reduce the columns through better programming practices.

I can't comment on using wacky libraries like glib, where function names are ridiculously long due to the lack of real namespaces. That may be a good exception to the rule.

ssam
April 13th, 2011, 10:05 PM
usually just let my editor soft wrap long lines. however if its wraps i take it as a hint that it is ugly code.

1clue
April 13th, 2011, 10:06 PM
I guess I have to agree with that, even though my company's width is almost double 80.

Our bible is readability, but our language is not c. We write web applications, and sometimes we're pushing text out. Sometimes it's just easier to read if the entire sentence or message is on the same line, especially since there is no handy IDE layout which uses all the rest of the space on our screens.

Most of the code I see is 80 columns or less.

llanitedave
April 14th, 2011, 07:19 AM
I find myself most comfortable with 120 characters. Using "natural" rather than cryptic variable names takes up a lot more space.

In Python, with its required indentation, the combination of nested indents and natural variable names makes the 80 character limit a bit tight. In this case, limiting your lines to 80 characters actually reduces readability, IMO.

I also use blank lines to set off code blocks so that the code doesn't appear crowded in the vertical sense.

I've experimented with different styles in different editors with different fonts and character sizes, and the 120-character line seemed to me to fall out as the most comfortable arrangement.

r-senior
April 14th, 2011, 09:35 PM
Interesting responses. =D>

I do stick to 80 columns with C, but Java (especially with Spring) and Objective-C are nigh on impossible with decent indentation. It was thinking about these that prompted the question.

1clue
April 14th, 2011, 10:02 PM
Ya, I'm doing java and grails with spring. Same thing, and the reason why sometimes I think it's easier to read a longer line.

Self-documenting code and all that. We rarely have comments in the code because the variable names are chosen to be most readable, which means they're not short unless it's a method-local or a standard across the app.

LoneWolfJack
April 14th, 2011, 11:57 PM
Everyone who programs there has at least one 1920xsomething monitor, so this leaves plenty of room on the side for other IDE panels.

same experience here. we just bought new monitors for all workstations in my company and they're all 1920x1080, so we cap lines at 220 characters.

nvteighen
April 15th, 2011, 03:05 PM
I didn't know that the 80-characters "rule" had a technical reason behind. I stick to it just because it's like a default.

Anyway, the exact number of characters is irrelevant; what you really need are conventions that make your code predictable to the reader. This means: the reader should be able to concentrate in the code as soon as possible, by making some clear conventions that ease the project's learning curve.

Blackbug
April 15th, 2011, 03:05 PM
well even at my workplace also, we adher to 80 character limit.
And, coding standards are almost generic now.
with emacs and vi, especially with emacs the indentations are easy to practice and quite generic.

my work is mostly in c++ so i can talk mostly about coding standards in c++.
certainly with C there are different practices, especially if we take into account opensource codebase (linux, wget, curl and etc etc..)

DarkHackerX
April 29th, 2011, 05:54 AM
Does you find people/places still adhere to the old 80-column rule?
Yes, we do on my project to reduce alot side scrolling.
Does it depend on which language is in use?
No, it changes from project to project.
Have you adopted, or been asked to adopt, a different standard, e.g. 132?
No.

worseisworser
April 29th, 2011, 06:23 AM
132 here. That gives room for two columns (buffers) at a time on each screen. I don't see myself needing all that space coding e.g. C though, but Lisp nests well and that's nice at times and I end up way to the right then:

http://static.nostdal.org/~lnostdal/temp/Screenshot-emacs%40blackbox.png