Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are 80 Columns Enough?

Zonk posted more than 7 years ago | from the good-enough-for-government-work dept.

Programming 763

ThinkGeek writes "Dating back to the venerable DEC VT100, the 80 column terminal has served us well for over 25 years. Even now, many open source projects and common conventions require lines of code and documentation to fit on that terminal. I am not alone, judging by code I've seen in and out of the open source world, in finding that number insufficient for coding, much less more verbose writing. Given that modern graphical displays (and all popular editors) are capable of far more, is it time we came up with a new standard-sized terminal? If so, what should the new standard be?"

cancel ×

763 comments

Sorry! There are no comments related to the filter you selected.

First Column! (4, Interesting)

Harmonious Botch (921977) | more than 7 years ago | (#19782991)

80 columns ought to be enough for anybody.

Seriouslly, IIRC, there still may be lots of old printers still functioning out there that use 132 columns.

Let's check that for ergnomics...my first computer had a 9-inch screen ( an old Kaypro, BTW ) and used 80 columns. 80/9 is about 9, so now with my 20 inch screen, 20 * 9 = 180... then scale things up a bit to allow for the eye fatigue that comes with age and 132 looks ok.

Re:First Column! (1)

julesh (229690) | more than 7 years ago | (#19783023)

You probably sit a little further away from your 20" screen than you did your 9" one. That said, bringing my editor out to full screen I see I can fit 162 columns on it without changing my font size, and I only have a 17" screen...

Re:First Column! (1)

Harmonious Botch (921977) | more than 7 years ago | (#19783195)

You probably sit a little further away from your 20" screen than you did your 9" one.
True. At least twice as far I think. Sorry, I should have stated that clearly in the first post. Implicit in the use of ratios in my first post is the assumption that I am using a constant field of vision ( about 30 degrees, FWIW ).

Re:First Column! (1)

Harmonious Botch (921977) | more than 7 years ago | (#19783389)

Ooops! Please ignore the above post. It has silly errors in it.

80 Columns? LUXURY! (5, Funny)

heretic108 (454817) | more than 7 years ago | (#19783323)

80 columns? That's all anyone needs.

In my day, I saved up for a year, delivering papers in the rain, to buy a board for a video display that gave me 40 columns x 16 rows. And that felt like sheer luxury!

Before that, I just had a 2 x 7-segment display, showing the hex codes of the characters as they came out of the UART at 110bits/s, and I used to translate them from the ASCII in my head in real time. As for input, I used to write it down on a piece of paper, then toggle it in with binary switches.

The kids these days have lines of 160 chars or longer. And they're still not happy, they're begging their parents for wider and wider displays. Soon you'll need a 30-inch wide display with a maximised editor window just to see the source lines without wrapping. But at least the kids will be able to say "7 lines? You think that's cool? I did it in 1!"

Re:First Column! (1)

erroneus (253617) | more than 7 years ago | (#19783041)

I always set my terminal screens to 132 columns.

My thoughts (4, Interesting)

julesh (229690) | more than 7 years ago | (#19783001)

I find I tend to work to about 100 - 110 columns most of the time. I'm not precise about it, but I find that that width
lets me use a readable font and still have enough space at the side of the code for a window with which to perform useful work (e.g. list of files in current project for easy access / unit testing GUI).

It's better for reading it (5, Insightful)

saibot834 (1061528) | more than 7 years ago | (#19783005)

I think it is easier to read it when the text is not all over the screen. That's why newspapers do that, too.

Re:It's better for reading it (4, Insightful)

Anonymous Coward | more than 7 years ago | (#19783075)

Code is not prose. Code should show structure (if it's not PERL ;-) ) and that makes life a lot simpler than having to read sequentially through the whole fscking thing.

Fewer columns (1)

phatvw (996438) | more than 7 years ago | (#19783169)

True, but wouldn't it be cool to combine the best of both worlds; increase comprehension and reading speed (micro pattern recognition) as well as structure (macro pattern recognition)?

Perhaps fewer columns is the way to go: http://venturebeat.com/2007/05/10/live-ink-offers- better-way-to-read-text-online/#more-10459 [venturebeat.com]

If newspapers set the standard (1)

ClosedSource (238333) | more than 7 years ago | (#19783127)

shouldn't we be holding up our display at arms length rather than have it sitting on our desks?

Re:If newspapers set the standard (1)

Ant P. (974313) | more than 7 years ago | (#19783247)

Dunno about you, but my display _is_ at arm's length.

Re:It's better for reading it (0)

Anonymous Coward | more than 7 years ago | (#19783291)

In the LaTeX documentation they say somewhere around 65 characters/line is the sweet spot for readability.

Re:It's better for reading it (1)

youthoftoday (975074) | more than 7 years ago | (#19783371)

I don't think humanity will ever develop past the stage we reached with LaTeX.

why is this an issue (2, Insightful)

PhrostyMcByte (589271) | more than 7 years ago | (#19783007)

We have the CPU power to do so much more now. We shouldn't need to manually wrap our lines - why can't the IDE intelligently wrap it for us, so that everyone gets their screen used to the fullest.

Re:why is this an issue (1)

LiquidCoooled (634315) | more than 7 years ago | (#19783039)

From a technical basis, its not the wrapping long paragraphs that has ever been an issue, its displaying and formatting tabulated information correctly without over-typing or making it look stupid.

Re:why is this an issue (5, Insightful)

Ritchie70 (860516) | more than 7 years ago | (#19783047)

Maybe because you want the new code to "look like" the old code in the same file?

Maybe because you're not using an IDE?

Maybe because if the IDE reformats all your code you wind up with the entire file as a diff when you check it in to your source code control system?

Re:why is this an issue (1)

rednip (186217) | more than 7 years ago | (#19783123)

We shouldn't need to manually wrap our lines - why can't the IDE intelligently wrap it for us
Generally, we don't need to wrap our lines, however those of us who only occasionally need to 'telnet to a box' often find ourselves needing man pages. They are the perfect example as it is standard (afaik) to write them to an 80 column display.

Re:why is this an issue (5, Insightful)

EvanED (569694) | more than 7 years ago | (#19783159)

Deciding how to wrap isn't always trivial.

What happens if you are doing an ASCII-art diagram that goes beyond 80 characters, and your editor decides to wrap it? Now it doesn't make sense.

If you have a line of code as such:

int foo; // this variable does such and such
and the comment goes beyond the wrapping, what should it do? Should it reformat it as

int foo; // this variable does
// such and such
or

// this variable does
int foo; // such and such
or

// this variable does such and such
int foo;
?

Sure, you could have a preference for these sort of things, but now if the editor does this, how should it save it? Should it put it back to the way it was before? But what if the programmer went to some effort to line things up for easier reading? Should it leave it with the line break in the new place? Now you've broken source control diff, even if you ignore white space.

You might be able to get an editor to do an okay job at this, but I don't think it's possible to make one that does a good job.

Re:why is this an issue (2, Informative)

EvanED (569694) | more than 7 years ago | (#19783197)

Bah, my second and third examples should have the '//' glyphs lined up. I previewed, but only glanced at the result and didn't notice.

Re:why is this an issue (0)

Anonymous Coward | more than 7 years ago | (#19783349)

What happens if you are doing an ASCII-art diagram that goes beyond 80 characters

Oh come on, that's a pathological case. I feel quite happy telling anybody doing ASCII art to fuck off and use a different system.

if the editor does this, how should it save it?

There's a simple, robust system that works just fine, requires no language-specific support and is easily implementable by the simplest text editors. Firstly, it saves it unwrapped. This means that whatever other system opens it can wrap to any width, you can change the width at any time, and it doesn't interfere with interpreters for the language you are writing or whatever. Secondly, as for the UI, you merely wrap it to the next line and provide some indication that the line is wrapped. Some text editors display a bar on the left side, for instance. Others provide a coloured indent. Some show a symbol.

You might be able to get an editor to do an okay job at this, but I don't think it's possible to make one that does a good job.

What is wrong with the system that I describe? It's compatible with everything, it's clear to the end-userm it's reconfigurable to any width at any time, and it works.

Re:why is this an issue (2, Informative)

suv4x4 (956391) | more than 7 years ago | (#19783181)

We have the CPU power to do so much more now. We shouldn't need to manually wrap our lines - why can't the IDE intelligently wrap it for us, so that everyone gets their screen used to the fullest.

Actually most IDE-s wrap it, and while it may be confusing at times, it works mostly well.
Well, most wrap it, except Eclipse. Power of the open source, huh* ..

* I am an Eclipse user.

Re:why is this an issue (1)

KZigurs (638781) | more than 7 years ago | (#19783211)

uh. now, since you are, apparently, writing code same way as I do...
BAD DOGGIE, STOP THAT 3 char indentation!
(and appending space after comment token is really no way to go. Learn to use C style comments only (in Fortran))

Re:why is this an issue (1)

petermgreen (876956) | more than 7 years ago | (#19783227)

why can't the IDE intelligently wrap it for us,
maybe i'm weired but I hate to have statements split accross multiple lines or multiple statements on one line. When you are working (or trying to work) in a one statement per line style then page width limits become about more than just text formatting!

Re:why is this an issue (2, Funny)

Anonymous Coward | more than 7 years ago | (#19783275)

Because that would fuck up my precious indentation. If you don't want to read my indentation as-is, you can print my code out, roll it up, and shove it in your ass.

Re:why is this an issue (1)

HomelessInLaJolIa (1125091) | more than 7 years ago | (#19783293)

We have enough CPU power to do more than any of us could ever imagine. Although don't expect that this means we *can* do everything we could ever imagine. It is all limited by the decisions of a few corporate bankers who have vested interests against the consumers. This all links back to the age old game of establishing, and maintaining debt-- modern day slavery without the traditional limitations.

Re:why is this an issue (1)

Goaway (82658) | more than 7 years ago | (#19783381)

Because even though we have unimaginable processing power now, open source programmers are still using software from the eighties to write their code.

Of course (5, Funny)

LiquidCoooled (634315) | more than 7 years ago | (#19783011)

Saying that 80 columns is not enough is like saying 640K is not enough and thats
just stupid, of course we know its plenty.

Re:Of course (4, Funny)

wildsurf (535389) | more than 7 years ago | (#19783173)

640 columns ought to be enough for anybody.

Be Glad You Don't Program Mainframe Cobol (4, Funny)

loxfinger (571135) | more than 7 years ago | (#19783015)

because if you did, you'd be limited to between 60 and 65 characters of code per line. Pardon me, I have to adjust my rainbow suspenders now.

It wasn't the VT100 (5, Informative)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#19783031)

The 80-column limit comes from the size of an IBM punched card.

Re:It wasn't the VT100 (4, Insightful)

Colin Smith (2679) | more than 7 years ago | (#19783331)

And the gauge of UK railway lines comes from the width of two horses arses.

I predict 80 column text will be around for a long long time.
 

Re:It wasn't the VT100 (4, Insightful)

OldManAndTheC++ (723450) | more than 7 years ago | (#19783341)

That's right. And IIRC, generally the first 8 columns were used for sequence numbering, so you really had only 72 columns for coding. Sequence numbers, of course, were vital for programs on punchcards -- if you dropped a tray of cards you had to have a way to put them back in order...

Ah the good old days ... whoops! gotta go, some damn kids are on my lawn ...

The Other Standard (1)

KagatoLNX (141673) | more than 7 years ago | (#19783037)

I don't know how prevalent it is, but there's already 132 columns. Various terminals support it and various printers as well.

If that doesn't work, I recall running accelerated text mode on a certain brand of video cards at 160x60 or somesuch.

Whats so difficult about this? (1)

RobertM1968 (951074) | more than 7 years ago | (#19783051)

Doesnt virtually every OS and their command line interfaces allow that number to be changed?

In OS/2 or eComStation, I simply have all command lines call a simple REXX script that changes them to 150,50 (cols,rows) or some other variant depending on the particular machine's maximum native resolution (and LCD size). This same script would work under XP and most previous versions of NT (with some limitations on the various cols,rows permitted). This works just as well at full screen command line as it does in VIO command line sessions.

The *nix setups should allow a similar task, just as easily scriptable.

So, what is the point here? Make it the default in your environment/build/whatever - and done deal!

Re:Whats so difficult about this? (1)

DaSH Alpha (979904) | more than 7 years ago | (#19783125)

Um, I think the whole point was that "why are many people still limiting their code to 80 columns?" Of course nearly every tool in use today supports customizing it, so the question is why don't we change that number in practice? It can be really annoying looking at code that's limited to 80 columns. For example, a coworker worked on some code that I'd done but their default eclipse preferences cause every file they touched to be wrapped at 80 columns (e.g. lines were now broken up) and it looked horrible now.

Re:Whats so difficult about this? (1)

statusbar (314703) | more than 7 years ago | (#19783317)

You know what is more annoying? Trying to edit code where there is ONE line of code that is over 2000 characters long!!!

--jeffk++

Fuck it. (0)

Anonymous Coward | more than 7 years ago | (#19783053)

I sure as fuck don't use 80 columns in my work.

Re:Fuck it. (1)

Rosco P. Coltrane (209368) | more than 7 years ago | (#19783237)

I sure as fuck don't use 80 columns in my work.

But then what do you do? photo editing? Excel sheets?

Really, one of the only areas where this 80-column thing still seems to matter is programming, simply because many many companies have a policy that says code should be 80-col formatted, and because there's a humongous pile of legacy code accumulated during that past 4 decades that is formatted that way, and because programmers just kind of like it because it allows having multiple files up in several text editors side by side, which is nicer than having to click to bring a window up each time you want to peek at some code.

Aside from programmers, I don't see who would want 80 colums though...

It shouldn't matter (1)

DigitAl56K (805623) | more than 7 years ago | (#19783055)

Why should it matter when we have line wrap? Hasn't HTML taught us to mark up documents for presentation on a multitude of different output devices? This would also be the case in a world where you did move away from 80 columns - you would need to consider writing for both 80 column and non-80 column devices, and depending on just how many standards you have the only way you can really ensure the presentation is to consider that you don't know much about the output device at all, which is what HTML does. Text mode graphical interfaces even become a similar concept, with tables representing windows perhaps.

Maybe we should consider implementing HTML-like terminals instead of changing the number of columns - which makes sense because then you can differentiate between 80 column output devices and HTML output devices. And most of us already have HTML viewers on our boxes.

Just don't invent a new fixed standard where somebody in 5 years time posts to Slashdot and asks, "Are 120 columns enough?".

Re:It shouldn't matter (1)

Antique Geekmeister (740220) | more than 7 years ago | (#19783145)

Because indentation matters. In C, Perl, Python, PHP, and even keeping Java legible, it matters in associating tasks done in the same set of code legible. And line-wrapped code is often more difficult to read.

Re:It shouldn't matter (2, Interesting)

DigitAl56K (805623) | more than 7 years ago | (#19783177)

Use blockquote or some other markup feature?

My suggestion is to use some kind of markup language to handle the formatting. There is no reason it couldn't include a feature to manage line wrap appropriately for both plain text and code.

Legibility (2, Insightful)

superbrose (1030148) | more than 7 years ago | (#19783385)

For people who hate comments, writing descriptive field names is often the only means to make their code understandable. Pseudo-code to make it clearer:

aVeryLongClassName {
  public function crasilyLongFunctionName(arg1, arg2, ..., arg10) {
    ...
  }
}

longResultValue = aVeryLongClassName.crasilyLongFunctionName(crazily LongArg1, crazilyLongArg2, ..., crazilyLongArg10);

looks better on one line than writing:

longResultValue =
aVeryLongClassName.crasilyLongFunctionName(
    crazilyLongArg1,
    crazilyLongArg2,
    ...,
    crazilyLongArg10);

I've seen some pretty nasty examples where the 80 column limit was obeyed but the result was code that was definitely unpleasant to read.

If your looking for logic in coding conventions (3, Insightful)

ClosedSource (238333) | more than 7 years ago | (#19783063)

your looking in the wrong place.

Yes, my spelling of "you're" was wrong twice but (4, Funny)

ClosedSource (238333) | more than 7 years ago | (#19783089)

at least I followed the same philosophy as many coding conventions that say that consistency is the prime directive.

Your grammar is wrong too. (0)

Anonymous Coward | more than 7 years ago | (#19783281)

...conventions which say that...

Re:If your looking for logic in coding conventions (4, Informative)

Rosco P. Coltrane (209368) | more than 7 years ago | (#19783135)

Actually, there is a logic in the 80 columns and 25 lines display: it so happens that 80x25 = 2000, which is just under 2048. That means with those 2K of video RAM (way expensive back then), you could use 2000 to display caracters, and use the remaining 48 bytes to store general display flags and statuses, or do whatever you like (I used to use that area in MDA video cards to store things back in my, ahem, virus-writing days...)

So in short, 80x25 optimizes memory usage.

Re:If your looking for logic in coding conventions (1)

ClosedSource (238333) | more than 7 years ago | (#19783239)

You realize that I was talking about the logic of coding conventions, right?

Re:If your looking for logic in coding conventions (2, Insightful)

Rosco P. Coltrane (209368) | more than 7 years ago | (#19783307)

Yes, and the 80 column line length convention derives directly from the hardware arrangement I explain above.

My point is that, contrary to what you seem to think, conventions don't just happen at random, there used to be a perfectly valid logic behind them, even if they seem to be lost to computer users nowadays.

Nah (5, Insightful)

bytesex (112972) | more than 7 years ago | (#19783081)

The origin of this post isn't that 80 columns on a terminal don't fit new code - it's some intern's Eclipse code, full of tabbed indentation and java.foo.bar myFooBarObject = new java.foo.bar(someInstanceIStupidlyNamedThis, someInstanceIStupidlyNamedThat); kind-a-code, that they want to give back to a real programmer, who can't fit it on his terminal. Guess what - you could have specified that the code can only be viewed in GUI-driven IDEs, or you could have deviated (oh the nerve!) from Sun's coding standards and use two spaces instead. And for the love of God, stop giving your variables names of 30 characters long that can really only be safely typed with some form of machine-driven autocompletion ! The rules are simple; use small functions with only three levels of indentation (max). That way your variables can be small too, since they don't have to describe the whole world. *Don't use tabs*. And everything will fit perfectly in 80 columns.

Intern?! (1)

iknownuttin (1099999) | more than 7 years ago | (#19783141)

The origin of this post isn't that 80 columns on a terminal don't fit new code - it's some intern's Eclipse code, full of tabbed indentation and java.foo.bar myFooBarObject = new java.foo.bar(someInstanceIStupidlyNamedThis, someInstanceIStupidlyNamedThat);...

I worked for a systems architect (15+ years experience, BS CS/EE from some prestigious school - not an MSCE holder.) that specified in his technical specs variables that had names that long or even longer! I asked him why and he said, "'C' allows it and it makes reading the code much easier and maintenance easier for the next guy. I couldn't argue with that.

Re:Intern?! (1)

bytesex (112972) | more than 7 years ago | (#19783255)

It depends on your language, I suppose - OO languages brought globals back (in a way) big time ! It's very difficult to examine even the shortest function to find a variable that you can't see being part of the parameter list or being declared somewhere in the function if you do (especially) C++. Is it a global ? Is it part of the class ? Is it part of one of the superclasses ? GUI IDEs go a long way to finding it, but it _does_ mean a context switch for a programmer. To avoid these situations (and where they do occur, prefix with 'this->') is best. And secondly, I find that really long variable names tend to produce a blur in my mind - I don't read to the end, and subtle differences between two can be hard to trace.

Re:Nah (1)

Antique Geekmeister (740220) | more than 7 years ago | (#19783165)

Are you single? Can I bear your children? Or if you have children, can I adopt them and use them to replace the cut&paste Perl programmers I have to keep slapping in the head for bad coding practices?

Here, I'll give you more tails (1)

ClosedSource (238333) | more than 7 years ago | (#19783179)

so you can wag more dogs.

Re:Nah (0)

Anonymous Coward | more than 7 years ago | (#19783199)

But the whole point of overindented, object-driven code with function and variable names that are longer than most sentences is so we can continue in our hacker tradition of not ever writing comments! When your variables name *are* comments, you don't need to describe what the variable is used for! ;)

I have a book somewhere from the 80s called "Structured Assembly Language." The included programs are quite readable, even though they're in intel assembler. Guess why? Good comments, and it *is* fairly structured (the author provides macros for loops, nesting, etc).

Re:Nah (4, Insightful)

pdbaby (609052) | more than 7 years ago | (#19783231)

*Don't use tabs*

Or just set the tabstop to 2, so developers can use whatever indentation size pleases them. Using tabs is nice, too: you're saying 'here be indentation' and not specifying the graphical representation of that indentation

Re:Nah (1)

suv4x4 (956391) | more than 7 years ago | (#19783277)

... it's some intern's Eclipse code, full of tabbed indentation and java.foo.bar myFooBarObject = new java.foo.bar(someInstanceIStupidlyNamedThis, someInstanceIStupidlyNamedThat); kind-a-code, that they want to give back to a real programmer, who can't fit it on his terminal. ... , or you could have deviated (oh the nerve!) from Sun's coding standards and use two spaces instead... stop giving your variables names of 30 characters long that can really only be safely typed with some form of machine-driven autocompletion ... use small functions with only three levels of indentation (max). ... *Don't use tabs* .... And everything will fit perfectly in 80 columns.

Nice, so we just gave up the likes of 15 years of programming language and IDE development, and what do we gain? Compatibility with 15 year old terminals. Amazing.

I think I'll pass though, and happily tab and autocomplete in my IDE.

Re:Nah (1)

pebs (654334) | more than 7 years ago | (#19783325)

And for the love of God, stop giving your variables names of 30 characters long that can really only be safely typed with some form of machine-driven autocompletion !

Java convention is generally to spell things out. It makes things more readable. Abbreviations are discouraged in most cases. Maybe its ok to shorten variable names, but you better not be shortening class/interface names into unintelligible abbreviations that only mean something to the person who created it. No one on my team is using notepad. We're all using Eclipse, and you better learn how to use auto-completion (for which Eclipse is excellent), otherwise you're going to be slow. If not for our own code, for all the code from libraries that we depend on. There are class names out there that read like sentences.

You can talk all you want about "real programmer". I used to code Java (and other things) in Emacs. And I still use vi for a lot of things. But for Java, I would be stupid not to use an IDE like Eclipse that makes me 20 times more productive. Eclipse makes it a joy to code Java.

I don't necessarily need my IDE to be graphical (though it probably helps). If I could get all the same features in a text mode editor I would be equally happy to use it. But I don't know of any Emacs/vi plugin that can achieve that.

Mods on crack again (1)

Harmonious Botch (921977) | more than 7 years ago | (#19783347)

Which moron modded parent 'troll'? He has a relevant point. Vigorously expressed, perhaps, but not enough so as to be a troll.

Psychological Thing (2, Insightful)

pixelfood (973282) | more than 7 years ago | (#19783083)

Because there is an imaginary border at 80, I rarely go over 100 columns (even though I could nest statements and create a much longer line). It probably helps keep my code readable.

Wasn't it the Romans who ... (1)

iknownuttin (1099999) | more than 7 years ago | (#19783099)

originally wrote in 80 colvmns and then when we got the to the middle ages, paper was the width of 80 columns, then typewriters of the 19th century were 80 columns to continue the tradition and then finally computer terminals of the 20th?

ITS OVER... (0)

Anonymous Coward | more than 7 years ago | (#19783101)

9000!!!

Old-skool ergonomics of line width (5, Insightful)

danpat (119101) | more than 7 years ago | (#19783103)

The desktop publishing fraternity has had rules for how wide lines should be for a very long time. Some of them are described here about.com [about.com] . Most of them place the ideal width of text for maximum comprehension at 30-60 characters. Notice how this is done with newspapers. Can you imagine how difficult it would be to read a newspaper that spanned articles across the entire page?

Code may have slightly different numbers, but I suspect they're probably not that different. 80 characters means you don't have to spent too much time seeking back to the start of the next line and you can read the code fast. When it comes down to it, almost all code formatting rules are about maximising their comprehensibility. While technology used to be the limiting factor, the human eye/brain is now the limit, and while we can do hundreds of characters per row now, you'd be hard pressed to find a person who could read text/code formatted like that easily.

Re:Old-skool ergonomics of line width (4, Insightful)

Rakshasa Taisab (244699) | more than 7 years ago | (#19783321)

You make an assumption that one reads the code like a newspaper. If you do, then you're doing it wrong.

Vertical structure is used for getting an overview of the code, horizontal for checking the details. If you split a lot of long lines, you are sacrificing the former without really gaining that much of the latter.

Even if 80 characters were enough in the 80's, it isn't today. One of the results of increased code complexity, tool-sets and higher-level languages, is that ambiguity and terseness must be avoided. When you're dealing with 3-4 different API's with thousands of functions, 8 letter function names would lead to insanity.

Re:Old-skool ergonomics of line width (1)

glwtta (532858) | more than 7 years ago | (#19783393)

Most of that is true (although code isn't the same as a block of text), but 80 is still low - something like 100 to 120 feels more comfortable.

Advantage? (2, Interesting)

pete-classic (75983) | more than 7 years ago | (#19783105)

What is the benefit of defining a new arbitrary limit? Assuming 80 columns is still useful. Do you think you can supplant 80 column? Or do you want to add another arbitrary limit, so that people can pick and choose?

Since 80 column is still immensely useful, why don't we stick with that where we can? For most other applications you can work in GUI land with dynamic wrapping and lovely variable-pitch fonts.

There is a relationship between how many characters you put on a line and how far apart the lines have to be to be readable. You might find that it is harder to improve on this venerable standard than you imagine.

-Peter

Re:Advantage? (1)

JustNiz (692889) | more than 7 years ago | (#19783225)

>> Assuming 80 columns is still useful.

No, lets not because it really isn't.

I have no limits... (1)

OptimusPaul (940627) | more than 7 years ago | (#19783109)

I don't use carriage returns or line feeds, it's unnecessary and just bloats the filessize. If people can't scroll or wrap the text on their own then they should be hauled off and shot. I used to omit spaces as well, but I found my code had trouble compiling, stupid compilers... 80 columns that's s0 20th century.

Don't count comments (2)

Richard_J_N (631241) | more than 7 years ago | (#19783117)

May I suggest that comments should not be included in this rule. I tend to keep the code always on the screen, but sometimes let comments scroll off-screen to the right (up to column 300 ish). This is because most of the time, I don't expect to re-read the comment very frequently, and by doing this, I can economize on vertical space.

BTW, I tend to work at about 200 columns on the desktop (20", 1600x1200), and 190 cols on my laptop (15", 1600x1200). I find the "Terminal [DEC]" font, or "Courier New" to be the best for clarity - having full hinting enabled (Ubuntu just works; Mandrake requires the patched libfreetype6), and anti-aliasing off.

A Piece of String (5, Insightful)

jumperboy (1054800) | more than 7 years ago | (#19783119)

As one of my teachers used to say when asked how long an essay should be, "As long as a piece of string." In other words, it should be as long as it needs to be to serve the subject. We've long overcome such limitations as the standard terminal size, and your document, whatever it is, can be as many columns as you want it to be, and often this can be adjusted by the reader (for example, the columns used to format markup code like this very HTML page you are reading are unrelated to the number of columns that are displayed). The only place I think this still matters is when preparing plain text documents, which are very readable at 80 columns. Unfortunately, content exists (like some URLs) that will always exceed the number of columns selected for readability. The optimum number of columns isn't something that scales infinitely with improvements in technology, it's a usability issue.

Why 80 columns is enough (1)

suv4x4 (956391) | more than 7 years ago | (#19783133)

Dating back to the venerable high-school years of my youth, the $10 bucks for food my mom gave me served me well for the entire day. Even now, if I have my breakfast and supper at home, with $10 bucks you still can get yourself a decent snack for lunch in most places. But can we do more?

I am not alone, judging by fat people all around me at work and neighborhood, finding a $10 snack for lunch insufficient, much less for a businessman like me who travels a lot. Given that I have enough money right now to afford 100, hell 1000 meals a day, why not make a good use of my money?

Bad programmers need more than 80 columns (3, Insightful)

phliar (87116) | more than 7 years ago | (#19783149)

Programs need to be readable by humans.

If you're playing, do whatever pleases you. But if you're writing stuff that others will have to read and maintain, you need to write clear and readable code. Break it up, for god's sake! No ridiculously long lines, and no code indented 42 levels deep. Learn to use functions and variables.

There's a reason newspapers and magazines have multiple columns of text instead of making the text run from the left side of the paper to the right.

Re:Bad programmers need more than 80 columns (1)

rg3 (858575) | more than 7 years ago | (#19783355)

I think it depends on the programming language. For C it's true that 80 columns should be enough. If you go much further, you may want to use auxiliar functions and such. However, in C++ and other languages, 80 columns is just not enough. By using two indentation levels (let's suppose an if block inside a function), you can easily get over 80 columns. There are some pieces of code that look ridiculous just because you're trying to limit them to 80 characters. For example, many standard library functions take 5 or more arguments. Just look at std::transform(), for example. It has a 5 arguments variant.

std::transform(left_operands.begin(), left_operands.end(), right_operands.begin(), back_insert_iterator(result), binary_func());

That line, which is pretty trivial and understandable for any C++ programmer, is already 130 characters long if you put a couple of tabs in front of it. If your terminal can display that in one single line, it's natural that you want to use only one line, because it should be read as a single operation, and you want to put one operation per line.

If 80 columns ain't enough (3, Informative)

tuxlove (316502) | more than 7 years ago | (#19783155)

then your code is too complicated and needs to be modularized. Or so said a professor of mine. He believed if you hit the 80th column that you should probably break your function down further into one or more additional functions. As a rule of thumb, this has served me well, about 95% of the time at least. Really, if your code is so many levels deep that it runs over 80 columns, it's probably difficult to keep track of things in there.

Re:If 80 columns ain't enough (1)

JustNiz (692889) | more than 7 years ago | (#19783189)

Thats baloney.
If you use sufficently explanatory variable names and a decent amount of white space to promote readability, 80 columns is definately not enough. Espcially for Java, where everything needs loads of casts.

80 seems fine for C (1)

OrangeTide (124937) | more than 7 years ago | (#19783167)

I suppose if you are using some bizarro language like Java or C++ or one of those ones with lookAtMyHugeClassName::MethodsCanBeReallyWordyToo that having more than 80 columns makes sense.

But being a plain old C programmer I think 80 columns is just the right size. When the screen is too wide it's harder to scan the text. I find it easier to stay "on-path" in my reading with a novel sized page than I do with an accounting sized page.

Ever notice that most text books break up text so it's 2 columns per page? It's because it's easier to speed read when the text is in a narrow area.

80 columns sucks (0, Offtopic)

mark-t (151149) | more than 7 years ago | (#19783183)

120 to 130 columns is ideal, IMO.

But when I was in college I had a prof in some of my comp-sci classes who would deduct marks for having code that didn't print cleanly... ie, code exceeded the right margin and would wrap around to the next line. I tried using a smaller printing font for one assignment so that I could use 120 column lines and ended up getting 40% deducted because of "poor presentation". I learned a lot from that professor's classes, in the end I think I learned stuff from him that I doubt I would have learned nearly as well with any of the other profs, but I always did think his marking standards were too high for undergraduate level.

Only 80 columns? (1)

bosko0 (785113) | more than 7 years ago | (#19783185)

Hell, some of my variable names are longer than that!

it depends on the language (3, Insightful)

petermgreen (876956) | more than 7 years ago | (#19783191)

some languages encourage/use in the standard libraries long identifier names and several levels of nesting (e.g. mainform.listbox1.items.delete(mainform.listbox1.i tems.count); ) if you want to keep your statements on one line each then you are likely to find yourself hitting the 80 column barrier quite a lot with such languages. Other languages (particularlly older ones such as plain C) have much shorter typical statements and so an 80 column limit really isn't a problem.

The only problem with 80 columns... (3, Insightful)

heretic108 (454817) | more than 7 years ago | (#19783207)

...is some of the identifier names that programmers in certain languages (hint: coffee) often come up with for their variable and method names.

RemoteHostProtocolMessageBuf remoteHostProtocolCommand = myConnectionToRemoteHost.remoteTransferManager.get NextSynchronousTransferCommand(maximumRemoteHostCo mmandBufferSize);

No Acceptable Standard (1)

Nom du Keyboard (633989) | more than 7 years ago | (#19783213)

No new standard will be any more acceptable for all uses than the 80-column standard has been. And, btw, that dates back to the Hollerith (IBM) punched card, which far predates the VT-100. And you don't even discuss whether or not to stick with fixed pitch, versus proportional spacing, characters.

My prediction: Any new standard you could come up with today would be obsolete far faster than the 80-column standard has managed. And besides, over 80 characters on a standard letter-sized paper line is hard to read, so why don't we just leave it as it is?

Yes it is enough! (1)

bjourne (1034822) | more than 7 years ago | (#19783215)

Shorter lines makes the text more readable. That is a fact that has been known forever in the printing industry and is why newspapers use multiple justified columns per page. In printing, you generally strive to make each line the same length. That effect is much eaiser to accomplish if you use short lines when coding. Otherwise you end up with lines that are 130+ characters long and others 5 characters, resuling in poor readability.

The other argument for short lines is that it becomes easier to view code side-by-side. I have a 24" LCD and can view three different source files side by side in a large enough font. That feature is very important when analyzing diffs for example. So please stick to 80 characters when coding. If you feel that you need more it is very likely that you are doing something wrong. For example, a long Java-esque method chaining that doesn't fit like this: "foobar.getBla().getMoo()...getBar()" probably should be splitted into many lines instead. If you run out of space because of to much indentation caused by deep nesting, it is likely that you should split out that section into its on function. Etc.

128x64 seems natural to me (2, Interesting)

ZyBex (793975) | more than 7 years ago | (#19783223)

Well, 128 columns has its advantages. And why not 64 lines? - powers of 2, like everything else in computing - screen math would be easier ans faster, just shift some bits to calculate the position - This would imply 40 columns to maintain the current proportion, though (or make it 42 - hi Douglas! :) ... I usually wish for more lines than more columns, and usually work with 50 lines; so I think it would be nice to default to 128x64 chars. Also, 80 columns exists for a reason; its the 640x480 standard resolution divided in 8 pixel columns. Changing to 128x64 would imply using a resolution of 1024x768, using chars of 8x12. Perfectly acceptable, I think.

80 Columns and VT100 (0)

Anonymous Coward | more than 7 years ago | (#19783233)

I'm all for keeping the VT100 and 80 columns as a minimum baseline mandatory standard. We don't want to do away with standards; rather we can add to them.

Codifex Maximus posting as AC.

Readability (1)

Spazmania (174582) | more than 7 years ago | (#19783235)

I am not alone [...] in finding [80 columns] insufficient for coding, much less more verbose writing.

There's almost always an efficient way to break up the section of code so that it fits in 80 columns. Doing so sensibly will usually make the code easier to read and understand.

That was largely true back when it was 40 columns on a TV screen for the Atari and Commodore home computers as well.

Using more than 80 columns to express yourself just means you're not as clever a programmer as you think you are.

words per line and readability (2, Insightful)

Charles Dodgeson (248492) | more than 7 years ago | (#19783249)

Many studies on print readability have shown that for English at least once you to more than about 13 words per line both reading speed and comprehension go down. Letter or A4 sized paper is great for handwritten text, but unless you leave wide margins (or use a very large font) it's inappropriate for print.

Book publishers know this. Look at your professionally published books around you. Where you see wide pages, there are either multiple columns per page or wide margins.

The 80 character width design was set up for a reason. Don't reject it without understanding the original reason and considering whether it still applies. It may not apply for code, but these choices should be considered carefully.

Two reasons why 80 is still a good number (1)

jjohnson (62583) | more than 7 years ago | (#19783253)

  1. Humans generally read best when the line of text they're reading is no longer than 12-14 words, which on average works out to around 80 characters. Longer lines cause the eye to frequently fail to stay on the correct line, losing the text and having to find it again. Since, generally, code should be readable, a guideline of 80 characters fits in well with the general human practice.
  2. Now that we have wiz-bang GUIs with high res monitors, we don't code with a plain text editor, we use an IDE that offers different features in panels that take up screen real estate. Write a line of code that spans a 2048x1600 screen, and you prevent me from nicely subdividing my IDE's workspace into code editor, project explorer, console output, etc. Sticking to lines ~80 characters long allows me to run an editor down the left side, and have several workspace panels on the right for convenience.

no... 80 columns is not enough (1)

GeekyGuru (685472) | more than 7 years ago | (#19783267)

I think those that write software on terminals limited to 80 characters need to either: 1) retire (you're obviously a fossil) ;) 2) stop being a cheapskate and upgrade your equipment More seriously now, I think a maximum of 100 or 110 columns should be the "new standard or convention" for the column width of source code files (I deal primarily with C/C++, so a different maximum may be better suited for other languages).

Its not about the size of the terminal ... (1)

trevorrowe (689310) | more than 7 years ago | (#19783271)

It doesn't really matter where 80 characters per line came from, I choose to keep my code at 80 characters / line for other reasons:

1) scanability (is that a word?)
2) facilitates faster code editing

No indents to the moon please (1)

bughouse26 (975570) | more than 7 years ago | (#19783289)

If you need more than 80 columns that probably means you have too many levels of loops/conditional indentation. Increasing beyond 80 columns exacerbates this poor coding habit. Learn to modularize. Functions shouldn't have more than 3 levels of loops/conditionals and should be less than 3 pages long.

jesus fuck! (0)

Anonymous Coward | more than 7 years ago | (#19783299)

when are these dumb ass questions going to stop hitting the front page?
 
80 columns was enough for your mom.

Code reviews are so much easier with 80 columns (4, Insightful)

bobharris (1125121) | more than 7 years ago | (#19783309)

Side by Side differences utilities (sdiff, vimdiff, gvimdiff, etc...) can show two 80 column wide windows without having part of the line truncated, or requiring left/right scrolling (assumes a large 1280x1024 monitor). Lines which are longer than 80 columns make it more difficult to review code changes (think of your code reviewer), and for other developers to maintain the code.

Not everyone has a 20+ inch monitor available to view long lines of source code, and some of those that do, still like to use 80 column windows. Also keep in mind that at home, some developers have small monitors attached to their home PCs or use laptops, and the only way to view long lines is to use tiny fonts that become difficult to read (especially if you are already wearing trifocals; remember some day you will be the one with trifocals!).

Lines which are longer than 80 columns makes it difficult to print source listings and get clean neat readable hardcopy. Yes it may be possible to get the printer to use a smaller font, but then we are back to poor eyesight issues.

windbg and other GUI debuggers can have multiple panes of debugging information displayed, but if your source pane is too wide it limits the amount of really useful debugging information you can have concurrently displayed.

Sometimes lines longer than 80 columns cannot be helped (like a table), but if they can be avoided by restructuring, or breaking the line into multiple lines and still maintain readability, it would be preferred.

Those are my reasons for preferring 80 column or less lines.

And as others have pointed out, 80 columns originated with punched cards.

Bob Harris

Elitist programmers.. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19783327)

..who always think they know best are the most conservative kind of computer users.

132 (1)

erotic piebald (449107) | more than 7 years ago | (#19783329)

132

80 colums is stupid. (1)

JustNiz (692889) | more than 7 years ago | (#19783353)

Please, lets move into at least the last quarter of the 20th century and finally kill this stupid 80 column de-facto standard once and for all.

Just about all hardware past about 1990 is capable of more than 80 columns display. There isn't a single display around today that is absolutely fixed at 80 columns. Even most VTxxx terminsals have a 132 column display mode.

The other retarded argument I've heard in workplaces that mandate 80 columns is that people seem to incorrectly think that printers still have a single fixed font, like the old line printer days or whatever.

Frcing programmers to break at 80 lines doesn't force shorter lines, it just forces line breaks to be inserted in the middle of them. This makes code really unreadable in comparison to not having a line length limit.

By and large programmers don't write stupidly long lines. Why make a rule to solve a non-existent problem?

No (0, Offtopic)

supasam (658359) | more than 7 years ago | (#19783361)

No. There should not be a standard terminal. The whole concept is quite outdated. Is much as you superior command line guys love it, there should be no terminal interface.

80 is perfect (1)

pestilence669 (823950) | more than 7 years ago | (#19783365)

I once worked on a project where a coder used a 155 character variable name. I never want to see anyone approach that size again.

Computer Formatting vs Automation (2, Interesting)

buckhead_buddy (186384) | more than 7 years ago | (#19783367)

As far as what actually displays the text, 80 columns is just a convenient default in this era of GUIs and IDEs. But the idea of 80 columns as a standard starts kicking over an ant hill of all sorts of other standards and conventions about code formatting (comments, tabs & white space, where do brackets go).

The last step of submitting code back to most projects these days is to format it according to the standard rules of the project. At least to me that's always seemed to be a non-productive workaround for lazy programmers. In most languages white space is meaningless and the burden of formatting is a burden on all of the programmers individually.

When the world of typewriter users started making adjustments to desktop publishing, a similar set of problems came up. How many spaces do we need to indent? How long should our lines run? Should we single-space or double-space? They quickly deduced the proper way to solve this was to let the computer (under direction of the editor or typesetter) to add the formatting. All the users needed to do was to submit the text in a way that such automatic tools wouldn't jam the automation.

In many ways, programmers don't want to make that jump for their own tools though. They've been using VT100 terminals, diff, and simply demanding everyone adhere to the same "sensible" standards for formatting. In these days of object oriented programming where names of classes start getting longer (Cocoa, Java, Ruby, to name a few) the standards seem more of a burden, but no one really feels the need to demand the code formatting be made independent of the code itself.

As horrible as it sounds, perhaps a tool that parses code into machine formatted XML for exchange and extracts it into code for use or viewing, is what's needed so that programmers can place the burden of "formatting" on the machine rather than the programmer. Technically it seems possible (with dynamic color coding and syntax checking that exists already). And yes, it sounds like a heinous burden both on storage and on users who prefer lightweight tools like dumb terminals. But it would simply be an extra step for a tool to extract the source into each person's personally preferred format rather than saying a certain convention will always work.

I wish programmers would wake up and realize that when they set standards like certain column length and white space conventions, they are actually working against automation and having the computer help them out. It sounds a lot like the old typewriter users who insisted "I don't need these fancy computers to help me out!"

and the answer is 42.... (0)

Anonymous Coward | more than 7 years ago | (#19783387)

The Answer is 42
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?