Are 80 Columns Enough?

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?"

First Column!

[Harmonious Botch]

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:

[julesh]

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...

80 Columns? LUXURY!

[heretic108]

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:80 Columns? LUXURY!

[Anonymous Coward]

You crazy kids, 80 colums?!? Pure non-sense!

In my day, we used primitive torches to burn binary dots onto chemically treated goat skin.
We then spent our evenings around the fire decoding the input, using sea shells with sand in them for each byte.
By morning, each shell was aligned and I could read the ASCII code out loud to debug my code.

For input, I used to craft copper drums out of ore and fuse the privative hand made capacitors to
each in a precise alignment. Then we entered in the machine code by charging
each capacitor we wanted with a simple clay jar battery and hand crafted wire mesh.

We did not have any electricity back then, so we had to hand crank the drums at a consistent
30 RPM as to synchronize it with the 60Hz clock of our main "Computer."

Re:80 Columns? LUXURY!

[Anonymous Coward]

OMG

We used communicate in binary, we would poke each other with live AC wires, each shock was a 1, though we could never tell if a 0 was really a 0 so we had to constantly ask each other. Eventually we decided to implement parity, we would stamp each other on the foot for every 8-bits.

This did take a while, by the time we had communicated a paragraph of Words we had forgotten what the first few were.

Re:

[WgT2]

...all this while walking up hill in the rain and snow.

Re:80 Columns? LUXURY!

[xarak]

Y
o
u

L
u
c
k
y

B
a
s
t
a
r
d
!

Re:

[countach]

Maybe arbitary conventions are the problem. Use however many columns you want, convention be damned.

Re:First Column!

[thc69]

Would you say that you botched that post in a harmonious way?

Re:

[erroneus]

I always set my terminal screens to 132 columns.

Re:First Column!

[mellon]

We've had 132-column terminals for a long time, but what I generally tend to jones for is taller, not wider. With a taller screen, you see more code. Then there's the whole issue of saccades, which is why for example newspapers do not run sentences horizontally across the entire page, but rather split the page up into columns. Your eye gets confused when the line gets too long - it's easier to read when there are fewer words on the screen. I suspect that when you use a lot of studlyCapsVariableNames that the eye tends to treat the whole variable as a single word, but there's still going to be a limit.

The question I would ask is a different one: why are we using such primitive typography in our text editors? We used to see all these *beautiful* demos of text editors that used proportional fonts, boldfacing, and the like, but you *never* see that in a production system. Some other folks here have mentioned automatic line breaking. One of the problems with that is that you want the bare text to look clean even when you're not in the fancy editor, but you can just have the editor automatically indent to the existing style in the text, but show you the style you prefer.

The programming editor technology we're using today is still very primitive. That's why coding styles are 80 columns.

Re:First Column!

[Kadin2048]

Then there's the whole issue of saccades, which is why for example newspapers do not run sentences horizontally across the entire page, but rather split the page up into columns.

Bingo.

Although I'm sure there are places where 132 columns are great (using ncurses-based displays that are smart enough to respond to your terminal size, for instance), I really wouldn't want a text editor that's much wider than 80 columns for normal use, lest it encourage people to create really, REALLY long lines of code or text.

Despite the arbitrariness of "80 characters," , it does seem to be about the maximum width that's comfortable to read in one go. (Take an un-hardwrapped text file and open it in a very wide editor and try to read it; it's a PITA compared to reading a narrow column.)

With code, where you don't want a ton of softwrapping, it makes sense to have a conventional editor width that's also comfortable to read.

Re:

[mgv]

Although I'm sure there are places where 132 columns are great (using ncurses-based displays that are smart enough to respond to your terminal size, for instance), I really wouldn't want a text editor that's much wider than 80 columns for normal use, lest it encourage people to create really, REALLY long lines of code or text.

Despite the arbitrariness of "80 characters," , it does seem to be about the maximum width that's comfortable to read in one go. (Take an un-hardwrapped text file and open it in a very

Re:First Column!

[that this is not und]

80 columns is the convention of IBM Punched Cards. Which go back to before computers. The old pre-computer databases consisted of decks of punched cards. Jumper panels were used with physical card sorters to 'sort' the databases. If you wanted to generate a mailing list only for certain fields, you would put the whole deck of cards in the sorter and have it pull out just the cards you wanted. You'd put that deck of cards in a reader connected to a printer and it was configured to print out the correct fields in the right place on labels.

This sort of 'data processing' long preceedes programmable digital computers. And the irony is that it's the kinda thing that many people in IT are still involved with. They're only incidentally involved with computers.

Re:

[Anne Thwacks]

80 columns is the convention of IBM Punched Cards. Which go back to before computers.

80 COlumns is the number of characters of 12 point fixed on a page of paper if you have decent margins. It probably goes back to Gutenberg or Caxton - anyway at least 400 years.

By now people have adapred to it, and our eyes expect 80 columns.

Re:First Column!

[Yaztromo]

No, 80 is not arbitrary. 64 or 128 would have been arbitrary.

I don't know the history, but 80 was a deliberate design choice that goes against the electronics in at least one obvious way.

IBM's most popular punch cards [wikipedia.org] from the 1920's onwards were 12 rows by 80 columns. A standard 80 x 25 video display can thus display two such cards stacked atop each other, with one row left over for displaying status information.

The cards were initially not intended for binary encodings (although that became possible later), and thus there was no "power of two" basis for them. The 12 rows were enumerated as 0 - 9, with two extra punch zones that acted, in effect, as control characters.

The choice of 80 columns was pretty much arbitrary -- indeed, IBM also made 51 column and 96 column cards at various points. 80 columns was big enough to record an 80-digit decimal number, and had no real special significance that I'm aware of.

And now you know how the worlds most popular punch cards continue to influence our computing experience.

Yaz.

Re:

[griffjon]

Now if we can somehow link punch card size to automobile size, we can expand the whole cars-based-on-horse-butt-sizes metaphor to cover code! woot?

Re:First Column!

[Rick.C]

IBM's most popular punch cards from the 1920's onwards were 12 rows by 80 columns. A standard 80 x 25 video display can thus display two such cards stacked atop each other, with one row left over for displaying status information.

Dude, that is so not true.

Each column of a punched card was one byte. Each card contained 80 bytes of data, which was one line on a terminal.

Re:First Column!

[martyros]

According to a computer documentation class I took (i.e., writing tech manuals), optimal numbers of letters per line for reading is 50-70. With 80 characters per line, most lines will wrap around to be on the high end of that range. As far as readability is concerned, 128 would be "right out".

Anyone know how many average characters per line old-school typewriters had?

Re:

[try_anything]

How do you maintain block indenting with proportional fonts!?

Blocks of identically-indented code continue to line up with each other. I suspect what you're asking is, "How do you use indentation to make two code lines that aren't part of the same indented block line up the way you want?" The answer is, you don't. If there is a very basic structural reason for them to be lined up, such as lining up successive lines in a long argument list, then a language-aware editor or IDE can handle it. If there isn

Re:

[pvera]

Exactly, I just don't understand why one would want to mess with something that has worked so well and across so many varied systems.

I went from a Tandy Color Computer 2 to a VAX 11/750 (WATFIV), then PCs, Mac Plus, VAX 11/780, more PCs, then alternating between Macs and PCs. The last thing that went through my mind was the column counts, except for WATFIV of course (first 8 columns and last 8 columns had to be kept blank).

Nowadays, I use iTerm [sourceforge.net] and it works very well, regardless of the kind of machine I con

Re:

[aldousd666]

You mean like, we should still be driving our horses with the first brand of buggey whips? Why change something that so obviously worked for so long?

Re:First Column!

[tacocat]

I would suggest that when you are writing code that is in excess of 80 columns you might be trying to do too much in one line. Sure I can write almost an entire program in one line with perl, but that doesn't mean anyone can understand what the heck I'm doing with it. But if I don't attempt to make everything fit into one line then I'm also going to tend towards more readable code, not more condensed.

I've been writing my own programs for a while now and have learned one thing from Perl Best Practices and a few other writings. Don't get cute with your code. If you can't read it easily then you can't maintain it either. I suppose you might have an argument for 132 columns if you can find most books and publications written in 132 columns. But I suspect you'll have a hard time with that.

The point in code, IMHO, is to make it readable. That's more important today than just about anything else. Computers are fast enough that you can afford to make some performance sacrifices for the sake of readability or ease of maintenance. If you need the speed, then write the program in machine language.

Re:First Column!

[gbjbaanb]

80 columns used to be the business when programs were written with short hand codes for everything - eg "strlen(custnme)", whereas nowadays you'd have "CustomerDetails.Name.Length()"

80-character limits are not goo dpractise anymore, simply because you can now fit more on one line and still have it readable, whereas you'd otherwise have to chop it up into several lines, or use abbreviations.

Re:

[marcosdumay]

"I would suggest that when you are writing code that is in excess of 80 columns you might be trying to do too much in one line."

Or you are writing Java code :) But I entirely agree (for most languages, there is a reason java has so many specific editors). When people decided to build 80 columns teletypes, they did it for a reason, and it was not because making wider paper was difficult.

Re:First Column!

[bigtreeman]

0. I agree, 80 columns is too much.
1.
2. Try forths 16 lines of 64 columns.
3. One screen is 1 KB of text, simple.
4.
5. Room on the 80 col screen
6. for line numbers and border.
7.
8. Factoring out code to shorter lines
9. makes for more readable code.
10.
11. Forth also has a shadow screen
12. of comment for each screen of code.
13. Code and shadow both fit on 132 column.
14.
15. Way too simple for amazing complex code.

Re:First Column!

[Doppler00]

Your 80 columns are an insult to my 24" screen, let alone those who have 30". Especially when you start using Java style notation where EveryVariableNameIsLikeThis() 80 columns is ridiculous.

Re:First Column!

[that this is not und]

Especially when you start using Java style notation where EveryVariableNameIsLikeThis()

By then, it's often too late.

Re:First Column!

[MadAhab]

That deserves a mod up. Too subtle for most to appreciate. But true.

And that's why 80 is right about right. If you need to indent that damn much, you should be refactoring. If your variable names are so freakin long, you need to refactor - your code is trying to do too damn much.

Even for reading normal prose, most websites try to prevent excessive width, as it harms readability. For code the rationale is different, but the end result is the same - too wide = illegible. If your code requires excessive width, then it is irreducibly illegible.

I'm going to leave python with it's "significant whitespace" out of this...

Re:First Column!

[jellomizer]

Well 80x25 May not be the best choice today. With 80 Columns just being what you can fit
  on Punch Cards. And what you can read most easially on those old 9" screen with very ver
y low DPI and Resolution. Some terminals went up to 132x50 but those at the time were ex
pensive. Also most PC hardware default Text Display is 80x25. So when developing code t
hat doesn't use graphics just text on the display assuming that worst case senerio people
will be running your app without X Windows so 80x25 is the safest bet without having text
  lobbed off or words wrapped in midword. There are a lot of people using linux systems wi
thout Graphics, to save resources for server settings and get that extra bit of memory from
  the system. So rule of thumb for text only apps, unless you change the screen resolution
stick with 80x25. Can we do better, sure but there will be no way that we can change the
default on old systems, so if you want your apps to work with the widest appeal stick with
  80x25 display. If they can do better fine, Or you can write your code with resolution dete
ction, but if you are not writting a text intensive or just want to save programming time 8
0x25 is the safest bet.

What? You never used continuation columns?

[crovira]

"With 80 Columns just being what you can fit on Punch Cards" just shows than you never used a "+" or a "*" in the continuation column.

It was essential when writing in PL/I or when using long variable names in COBOL. (Got to make all those MOVE statements line up pretty.)

Never mind what we used to do to line up FORTRAN code.

After 1975, it was never about what the compiler could handle (I've written quite a few deblank() routines in my time,) it was about what we, the human writers, could handle.

Re:

[Javagator]

so I can look at multiple files at the same time

I program the same way. I am always referencing other parts of my code, or code that I wrote last year. I usually have at least two Emacs sessions open, a terminal or two, and a file system navigator or two. With screen real estate at a premium, I keep my Emacs windows at 80 columns.

And, with my programming style, I don't really need long lines. I just scanned a 400 line Java class that I wrote and I only have 3 statements that don't fit on 1 line.

Re:

[WilliamSChips]

Hungarians are the Magyars, not the Huns. The Huns were from Mongolia. Also: I occasionally use CamelCase when I'm about to say some phrase that's fairly common but that's because I UseWikisTooMuch.

Re:First Column!

[hobo sapiens]

The Huns were European / central Asian, a long way from Mongolia. They controlled a large area in the final days of the Roman Empire (the one based in Rome, not Constantinople.) While it is held by some that Attila the Hun was of Mongolian origins, the area over which his rulership held sway was in what we would consider Europe / the Caucasus.

http://www.boglewood.com/timeline/attila.html [boglewood.com]
http://ancienthistory.about.com/cs/attilathehun/a/ attilathehun.htm [about.com]
http://en.wikipedia.org/wiki/Attilla_the_hun [wikipedia.org]
http://www.newadvent.org/cathen/02061b.htm [newadvent.org]

Also, that the Huns were not the descendants of the Hungarians is a bit in question (see http://en.wikipedia.org/wiki/Maygar [wikipedia.org]).

All this in a story about 80 column terminals. This is, like, a tangent of a tangent of a tangent. But then again, that's what makes /. so enjoyable!

Re:

[Schraegstrichpunkt]

. . . or *gasp* the evil that is Hungarian notation.

Systems Hungarian or Apps Hungarian? [joelonsoftware.com]

My thoughts

[julesh]

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

[saibot834]

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

[Anonymous Coward]

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.

why is this an issue

[PhrostyMcByte]

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

[Ritchie70]

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:

[Urusai]

You shouldn't base your optimization decisions on the inadequacies of related technologies. You should fix the other stuff. Personally, I don't see any reason to use fixed-width except that our freakin' teletype-emulating terminals would need an updated protocol to handle it, and we all know that UNIX and friends think that VT100 is the end-all of user interfaces.

Re:

[mypalmike]

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?

This is why a code formatter should be part of the source control checkin process.

Re:

[rednip]

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

[EvanED]

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:

[xjimhb]

What if you are writing APL programs? The classic APL one-liner could easily require a screen width of 1000 characters or more. I can recall a class I was taking, the Prof put up an example which flowed across FIVE or SIX blackboards. If we're going to come up with a new standard, shouldn't we take this into consideration?

Re:

[suv4x4]

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:

[cratermoon]

There's a solution to that, if you follow a simple rule.

NEVER check in both reformatting AND any other change at the same go. ALWAYS reformat file -> checkin -m "formatting change only" -> make change, checkin -m "actual change message". Result: "diff current-2, current" has all the meaningful information you want, while "diff previous, current" will show only the formatting changes just in case you have a programming language where whitespace counts or some other pathological line-break factors can

Re:

[suv4x4]

"And just to stay on topic: human factors researchers have found that a line length of 65-70 is best for scanning. That leaves 10 or so columns for assorted decorations and programming language requirements (FORTRAN, I'm looking at your columns 1-6)."

Were those researchers using Apple II.

Code isn't just "any text". There's lots of indenting, and colorized syntax helps scanning immensely.

I've been using 80 columns to this day for comments, but the immense wrapping was pissing me off last couple of months. I

Re:

[Duhavid]

Working with VB and VB.Nyet, I have to tell you that having the
IDE do much of anything like this for me only serves to royally
piss me off. I have been working in these for a number of years,
off and on, and it continually manages to be a source of
infuriation to me. I doubt you will like the results.

Re:why is this an issue

[UserGoogol]

You can, but code is structurally very different from English language text. With text, you just have long streams of text arranged as paragraphs which can be squished pretty thoroughly and maintain their overall form. Code, on the other hand, uses whitespace extremely meaningfully with carriage returns and indentations arranged according to a lot of different rules. It probably wouldn't be so hard for the IDE to have a system which cooperates "okay" with the current system already use, but it would still be a change, and thus would be unpleasant for many. (And introducing a new text formatting system that some people use and some people don't introduces further problems.)

Of course

[LiquidCoooled]

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

[wildsurf]

640 columns ought to be enough for anybody.

Be Glad You Don't Program Mainframe Cobol

[loxfinger]

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.

Re:

[ScriptedReplay]

Hah! I knew I had reason to be grateful for the luxury of Fortran's 72 characters per line! You Cobol guys need to start catching up with the times, ya know.

It wasn't the VT100

[Beryllium Sphere(tm)]

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

Re:It wasn't the VT100

[Colin Smith]

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:

[robbak]

But its a really, really nice one, you'll have to admit.

The addendum: Width of shuttle booster rockets = width of tunnels - clearance = f( width of tracks) : is also amusing.

Re:It wasn't the VT100

[Colin Smith]

No, it isn't.

The first railway, colliery lines for transporting coal in the UK were pulled by horses.

 

Re:It wasn't the VT100

[OldManAndTheC++]

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 ...

Re:

[Doctor Memory]

Actually, I think the author got it backwards: the VT-100 was the first terminal to support more than 80 columns. At least, it was the first one I ever saw. Most of the terminals we had around that time (evil ADM-3s and -5s, MiME-1s, VT-52s and those beautiful but useless Tek 4010/4014s[0]) would do the standard 80x24/25, and several sported "enhanced" character sets (bold, blinking, underlined, double-wide, etc.). The (DataMedia?) DT-80 was a VT-100 clone and supported 132 columns too. Oh, and soft scr

Re:

[MichaelSmith]

Urban myth perhaps? There's no relation between screen widths and punch cards.

The mainframe which I used at college ran an IBM OS. If I wrote a 15 line script to run a batch job the OS would send me back a message saying 15 cards read.

Additional historical info

[Count_Froggy]

According to several sources (summarized in this Wikipedia article, http://en.wikipedia.org/wiki/Punch_card/ [wikipedia.org], the 80-column card format was formalized by IBM in 1928 on the size of the 1928 US Dollar bill. Almost everyone has copied this format, making it the 'standard' when the earliest digital computers were built. So, when the early terminals came out, it was natural to have screens the same width as the earlier card format. Early personal computers used a variety of formats from 40 character (e.g., Apple ][) to 64 character (e.g., TRS-80) to 80 character, but most moved to the 80 character 'standard'. Also, the early typewriter convention of 10 characters per inch (non-metric) results in 80 characters across a US Letter sized (or even A4) sheet of paper with some margins. This lent a lot of impetus for the glass terminal to be the same as the earlier paper terminal.

The Other Standard

[KagatoLNX]

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?

[RobertM1968]

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

If your looking for logic in coding conventions

[ClosedSource]

your looking in the wrong place.

Yes, my spelling of "you're" was wrong twice but

[ClosedSource]

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

Re:If your looking for logic in coding conventions

[Rosco P. Coltrane]

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:

[Rosco P. Coltrane]

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

[bytesex]

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.

Re:Nah

[pdbaby]

*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:

[Jugalator]

I agree, that's exactly why I use tabs. For flexibility for the reader.

The important thing is not to mix tabs and spaces.

God, I remember when we used emacs for coding Java. I'm not sure if the default installs were just stupidly configured, but emacs used 2 space indentation (with spaces) and if there were two indents, it replaced it with a tab! And then of course -- three indents = 1 tab + 2 spaces. OMG the frustration that always caused. :-#

I don't even understand why so many IDE's *support* that setting.

Re:

[coaxial]

Doesn't work dude. Sure it make sense, but it doesn't work in practice. People don't know how set their tab stops, and thus start using spaces. Soon you have a mess where nothing is aligned on anyone's computer. Just use spaces. It's the only thing that works. But of course, then you have someone using tabs because because they're not going to bother hitting 8 spaces, and anyway Joe over there hits tab all the time, and it none cares. (Little does he know that Joe's editor is actually inserting space

Re:Nah

[MichaelSmith]

*Don't use tabs*. And everything will fit perfectly in 80 columns.

But isn't that the point about tabs? I type a tab and display it as four characters. You get my code but display tabs as two characters. If they were used properly everything should scale correctly.

With some people working in Eclipse with CheckStyle and checking in to VCS and whatever else I really wonder if our modern coders would be better off working with some sort of symbolic database of instructions, instead of messing with code.

Psychological Thing

[pixelfood]

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.

Old-skool ergonomics of line width

[danpat]

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

[Rakshasa Taisab]

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:

[The Man]

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

And you make an assumption that you should name every variable and function as if it were a sentence. If you do, then you're doing it wrong. Names in the 10 to 20 character range are reasonable; names in the 40 character range are not. Many locals can and should be given names like i, j, k, p, and q, and in any case don't need to be prefixed. And under those circumstances, it should be possible to ge

Modern code.

[Savage-Rabbit]

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.

Lets not forget that these days there are people who write functions/methods/constructors with 20+ parameters and manage to create lines of code running into 350+ characters. I know that sounds insane but I actually saw a piece of code recently where a developer was passing the same set of over a dozen parameters all over the place and this is not even the worst I have seen. Back in the stone age when I was learning C++ they used to tell us that if you find yourself regularly having to pass around the same set of, say... 4 or more variables you write a struct or a class to encapsulate them and pass that container. Judging from some of the code I get to see these days that seems to have gone out of fashion. I write OO code in multiple languages including Java and C++ and I know lines of code can get longer than they used to in golden oldie languages like C but it's still not that hard to keep your line length reasonably short. It also helps with readability. That being said when I write code in terminal windows I find 80 characters somewhat restricting. Having 100-120 characters to work with per line is what I'd like, more than 200 is IMHO to much.

Advantage?

[pete-classic]

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 ha

Don't count comments

[Richard_J_N]

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

[jumperboy]

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.

Bad programmers need more than 80 columns

[phliar]

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

[Abcd1234]

What you say may be true for languages like C, but take Java: your code *immediately* starts off indented two levels deep, first for the class, second for the method block. Hell, with .NET, it's *three* levels, once you throw in the namespace declaration. Then throw in a loop, a synchronized block, and an if statement, and you're suddenly 5-6 levels deep, which, if you're using 4-character tabs, is 20 characters. Couple that with fairly verbose method names, and 80 columns starts to look incredibly ridiculous, as you're suddenly forced to break large boolean expressions and method parameters up across multiple lines, which only makes the code *less* readable, IMHO.

Sorry bud, but anyone who actually believes 80 columns is good enough clearly hasn't been doing much serious coding lately.

Re:Bad programmers need more than 80 columns

[Solandri]

std::transform( left_operands.begin(),        // Lining up arguments vertically makes it easier to
                left_operands.end(),          // figure out which is the nth argument in a long list.
                right_operands.begin(),       // And a long list of arguments is precisely when you
                back_insert_iterator(result), // risk exceeding 80 columns of text.
                binary_func() );              // So 80 columns promotes easier-to-read code?

If 80 columns ain't enough

[tuxlove]

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.

it depends on the language

[petermgreen]

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...

[heretic108]

...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);

words per line and readability

[Charles Dodgeson]

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.

Code reviews are so much easier with 80 columns

[bobharris]

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

Computer Formatting vs Automation

[buckhead_buddy]

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!"

Re:

[ardor]

Please, stop the XML overuse.

What you suggest is yet another XML mess. Embedding SVG in code is pointless; SVGs are resources. Also, UML is not the silver bullet that will replace programming languages; its just not nearly as powerful. C++ metaprogramming and generic programming with UML? Lisp magic with UML? System programming with UML? Erlang-style threadlets with UML?

UML diagrams are good tools for representing an overview, and for brainstorming ("hey, what if we change this class inheritance to this one

Nothing to do with the number '80'

[m.dillon]

The issue has nothing to do with the number 80, and everything to do with readability and understandability. Most projects require certain limitations to terminal width for just that purpose because it has been amply shown in the past and continues to be shown today that when you DON'T put such restrictions on submissions you wind up with an unreadable mess. This is the same problem we have with idiots who set their hardware tabs to '3' and expect anyone trying to read their source files to do the same, or who decide that comments should be tabbed out to column 100 regardless of anything else. People do all sorts of crazy things and it might work if every single line of code in a project is your own, but certainly doesn't work when you are incorporating submissions from dozens of different people. You very, very quickly hit diminishing returns on your ability to efficiently read and understand a source file as you increase the number of columns. Increasing the number of rows is not a problem and actually improves one's ability to read and understand the contents of a file. But increasing the number of columns doesn't work the same way. Usually all it does is create a mess if you actually try to fill in all that space. 80 is not too small, and not too large, not really. That's why projects continue to use it. -Matt

Why flat files in the first place?

[OzPeter]

Rather than talk about the number of columns in a flat file, I think the issue should be more about why we are still using flat files to write source code in the first place. Why are we still doing this? Why not a programming mark up language akin to way that HTML is a presentation language? In that way people could display code to their preferences and this entire issue would be moot.

Re:

[Comatose51]

Source code files aren't flat files! Source code already have structure built into that. That's why they can be parsed and compiled. HTML and XML add structure to otherwise unstructured data. This is definitely not the case with source code. You can set your IDE to display your source code a certain way if you want. In short, marking up source code is redundant and unnecessary.

Thc Consensus: Programming text ~= 60 + indenting

[robbak]

This seems to be the Consensus: That your text should be in the order of 60 columns, but the indenting (especially in 'modern' languages) may take you well over the 80 column mark.
In the more 'classical' languages (C, C++), more than 4 levels of indent is a sign that your code is too complex, and needs to be refactored. ( for{while{if{if{if{}else{for{while{}}}}throw (brain); ) In Java or C# the language constructs add some levels too. (Should one consider not indenting for these "always there, ignore them" levels??? I know I do! (ie: If I was using a namespace declaration, I would just type "namespace name { } //namespace name" and then forget about it.))

Punched cards, baby

[mbone]

This way predated the VT 100.

Punched cards (which is how I first programmed) came in 80 and 132 character widths. Since
IBM machines read the punched cards, it was natural for IBM systems to be built on the same widths.

I remember vividly email in the 1980's where if you sent emails with long lines to people on IBM mainframe
machines, the results were basically undefined. Every time that would happen, I would think "punched
cards strike again!"

Bigger Punch Cards?

[wonkavader]

80 columns are what you need for punch cards. That's why screens are 80 columns wide. Ergo, if you make them wider, you need to design NEW PUNCH CARDS. That could be very expensive.

Punch cards were based on the civil war era dollar bill. I cannot think of a currency in the world with a longer bill size than that (Somebody else know one?), so I can't think where we'd get the model. Maybe we'd make each card the size of an apartment lease.

I'm against it.

Be Flexible

[Archie Gremlin]

Personally, I haven't had to edit code with a fixed width terminal for 15 years. Consequently, my personal coding guidelines are a bit more flexible than this.

I format code to maximise readability and minimise the number of lines. (in that order) As far as possible I try to complete a line of code in under 80 characters. I'll happily stretch a line up to 100 characters to avoid a line break that makes it harder to read. I'll allow lines that are basically a single, very large token to extend much further than that. This usually means string literals.

I break comments and javadoc at 70 characters because it improves readability.

This means that my code is still readable if I print it out and the printer truncates the long lines.

For what it's worth, the windows I'm editing code in at the moment display 90 to 100 characters.

Re:

[DigitAl56K]

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.

Re:

[GomezAdams]

Does anyone remember Hollerith? He devised the card for the 1880 census and it was that card that was standardized on. Hence in FORTRAN you have a Hollerith constant, meaning a string of 80 characters - if I recall my college days correctly