Are 80 Columns Enough? 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?"
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.
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).
Advantage? (Score:2, Interesting)
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:It shouldn't matter (Score:3, Interesting)
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.
128x64 seems natural to me (Score:2, Interesting)
Computer Formatting vs Automation (Score:3, Interesting)
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:why is this an issue (Score:3, Interesting)
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:It wasn't the VT100 (Score:3, Interesting)
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.
Re:why is this an issue (Score:3, Interesting)
Why flat files in the first place? (Score:4, Interesting)
Nothing to see here, move along.... (Score:2, Interesting)
But that's all irrelevant. You're looking for one of those backward compatibility issues, like the QWERTY keyboard and those railroad tracks supposedly designed by the ancient Romans [snopes.com]. You won't find one here. Sure, terminal emulators and text editors typically default to 80 columns — but they all let you change that default.
The fact is, when you're editing source code, you need to put some reasonable limit on your lines. If you don't, your code is a nightmare to maintain. Doesn't have to be 80 columns; I use (stops to look at his
Or are do you dislike having any limit? That would mean that you don't have any trouble reading source statements that wrap at random places. Well, goodie for you, but most of find that a pain. That's why software projects like you to use 80-column code lines. It has nothing to do with any fossilized VT100 meme.
As for "more verbose writing": if your prose is so nonconcise that you need longer input lines, you need to take a writing class.
I really don't get the issue here. Is it because you can never remember to hit ENTER? Neither can I. Or most people. That's why God invented typewriter bells and text editors with autoformat modes.
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.
Re:First Column! (Score:3, Interesting)
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 connect to. My only real source of aggravation is that in that rare occasion that I need to type a DOS command in a Windows server, the clipboard can't be accessed with keystrokes, it has to be done through menu choices.
Re:Old-skool ergonomics of line width (Score:3, Interesting)
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 get 3, possibly 4 levels of indentation into a single function without excessive line breaks or other loss of readability. If you need more than that, you need to refactor or rephrase the function. If you can't find unique names that are both comprehensible and short enough not to demand more columns, you need to reevaluate both your architecture (you're probably not managing namespaces and/or symbol visibility well) and your naming conventions (consider prefixes of 2 or 3 characters instead of 8 or 10, for example). And don't even get me started on languages like C++ that force you to type SomeLongThing::SomeOtherLongThing::SomeEvenLongerT hingWithATailAndFourteenLegs.
It's completely possible to write readable, maintainable, well-architected code within 80 columns. And before you say "sure, as long as it's nothing more useful than Hello World," know that it's possible for such code to solve large, difficult, and complex problems without violating any of those constraints. Countless examples abound; look at the OpenSolaris kernel code for some good ones. It is, admittedly, very difficult to write egregiously verbose, needlessly complex, badly architected code in 80 columns, especially in languages designed primarily to increase complexity. So go ahead, use more than 80 columns. That's fine with me, actually; that way I'll know immediately that your code is a pile of shit without having to spend even 30 seconds actually reading it. Think I'm joking? In fact this is a real and widely-used litmus test for bad code and bad engineers. Unless it's an intern candidate who doesn't know any better, no one who sends me a code sample with long lines would ever get an interview, because I won't even read it.
Modern code. (Score:4, Interesting)
yes, 80 columns _is_ enough (Score:2, Interesting)
Second, 80 columns is enough to get a decent amount of text on a display, and also code if your indent step isn't insanely wide. And it's narrow enough to read a line at a glance instead of having to scan along it. That seems a core tradeoff to me, that 80 columns does well.
Having a widely accepted standard width provides various benefits: everyone's already aware of it and many people use it, and thus people can plan for it. Example: my standard environment has 4 80-column terminals side-by-side on a 1600 pixel display. If some loon moves to a gratuitously wider format I'll forever be mangling his code when it displays.
The "finding that number insufficient for coding" argument doesn't wash with me; it generally means you're writing stuff too cumbersome for someone else to easily read. You can always break lines or subdivide code chunks. When I, personally, don't take that trouble it's usually laziness, not because I'm doing something inherently complex.
For "more verbose writing", I'm assuming you mean prose. If so, you should be using a format that lets people reflow the text (eg HTML or the format=flowed plain text syntax for MIME messages); then you can work in whatever you like and I can reflow the paragraphs on my nice 80 column display. That way we're both happy. I'm doing that right here, in HTML.
You write "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?" No, it isn't. More pixels lets me get several terminal side by side, (man page, shell, code, output windows etc). A wider "standard terminal" will only make that harder.
I do use wider terminals for some things, but they're mostly output windows with wide line-formatted logging. No window will ever be wide enough to fit them all, and when I use a wide terminal it only helps these pathological things, and does not solve the whole problem. So i don't consider it an argument for a wider "standard width".
Re:It wasn't the VT100 (Score:3, Interesting)
The addendum: Width of shuttle booster rockets = width of tunnels - clearance = f( width of tracks) : is also amusing.
Re:why is this an issue (Score:3, Interesting)
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 change how the code works.
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).
Thc Consensus: Programming text ~= 60 + indenting (Score:3, Interesting)
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 { }
Re:First Column! (Score:2, Interesting)
Re:First Column! (Score:3, Interesting)
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:why is this an issue (Score:3, Interesting)
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 just switch to 132 and it's just perfect.
Re:It dates back well before the VT100 (Score:3, Interesting)
Re:First Column! (Score:1, Interesting)
Re:First Column! (Score:3, Interesting)