Slashdot Log In
Are 80 Columns Enough?
Posted by
Zonk
on Sat Jul 07, 2007 04:34 PM
from the good-enough-for-government-work dept.
from the good-enough-for-government-work dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
First Column! (Score:5, Interesting)
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! (Score:5, Interesting)
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.
Parent
Re:First Column! (Score:4, Insightful)
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.
Parent
Re:First Column! (Score:5, Informative)
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.
Parent
Re:First Column! (Score:5, Informative)
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.
Parent
Re:First Column! (Score:4, Informative)
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.
Parent
Re:First Column! (Score:4, Informative)
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?
Parent
Re:First Column! (Score:5, Insightful)
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.
Parent
Re:First Column! (Score:5, Insightful)
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.
Parent
Re:First Column! (Score:4, Informative)
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.
Parent
Re:First Column! (Score:5, Insightful)
Parent
Re:First Column! (Score:5, Insightful)
By then, it's often too late.
Parent
Re:First Column! (Score:5, Insightful)
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...
Parent
Re:First Column! (Score:4, Insightful)
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.
Parent
80 Columns? LUXURY! (Score:5, Funny)
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!"
Parent
Re:80 Columns? LUXURY! (Score:5, Funny)
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."
Parent
Re:80 Columns? LUXURY! (Score:4, Funny)
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.
Parent
Re:80 Columns? LUXURY! (Score:5, Funny)
o
u
L
u
c
k
y
B
a
s
t
a
r
d
!
Parent
Re:First Column! (Score:5, Funny)
Parent
Re:First Column! (Score:4, Informative)
http://www.boglewood.com/timeline/attila.html [boglewood.com]
http://ancienthistory.about.com/cs/attilathehun/a
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
Parent
My thoughts (Score:5, Interesting)
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 (Score:5, Insightful)
Re:It's better for reading it (Score:4, Insightful)
Parent
Of course (Score:5, Funny)
just stupid, of course we know its plenty.
Re:Of course (Score:5, Funny)
Parent
Be Glad You Don't Program Mainframe Cobol (Score:4, Funny)
It wasn't the VT100 (Score:5, Informative)
Re:It wasn't the VT100 (Score:5, Insightful)
I predict 80 column text will be around for a long long time.
Parent
Re:It wasn't the VT100 (Score:4, Informative)
The first railway, colliery lines for transporting coal in the UK were pulled by horses.
Parent
Re:It wasn't the VT100 (Score:5, Insightful)
Ah the good old days
Parent
Additional historical info (Score:5, Informative)
Parent
If your looking for logic in coding conventions (Score:4, Insightful)
Yes, my spelling of "you're" was wrong twice but (Score:5, Funny)
Parent
Re:If your looking for logic in coding conventions (Score:5, Informative)
So in short, 80x25 optimizes memory usage.
Parent
Nah (Score:5, Insightful)
Re:Nah (Score:5, Insightful)
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
Parent
Re:Nah (Score:4, Insightful)
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.
Parent
Old-skool ergonomics of line width (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Parent
Modern code. (Score:4, Interesting)
Parent
A Piece of String (Score:5, Insightful)
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.
it depends on the language (Score:4, Insightful)
The only problem with 80 columns... (Score:4, Insightful)
Code reviews are so much easier with 80 columns (Score:4, Insightful)
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
Why flat files in the first place? (Score:4, Interesting)
Re:why is this an issue (Score:5, Insightful)
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?
Parent
Re:why is this an issue (Score:5, Insightful)
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: and the comment goes beyond the wrapping, what should it do? Should it reformat it as or or ?
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.
Parent
Re:why is this an issue (Score:5, Insightful)
Parent
Re:Bad programmers need more than 80 columns (Score:5, Insightful)
Sorry bud, but anyone who actually believes 80 columns is good enough clearly hasn't been doing much serious coding lately.
Parent
Re:Bad programmers need more than 80 columns (Score:5, Insightful)
left_operands.end(),
right_operands.begin(), // And a long list of arguments is precisely when you
back_insert_iterator(result),
binary_func() );
Parent