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.
Re: (Score:2)
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!"
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."
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.
Re: (Score:3, Funny)
Re:80 Columns? LUXURY! (Score:5, Funny)
o
u
L
u
c
k
y
B
a
s
t
a
r
d
!
Re: (Score:3, Interesting)
Re:First Column! (Score:5, Funny)
Re: (Score:2)
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: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.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Informative)
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! (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.
Re: (Score:3, Funny)
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.
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?
Re: (Score:3, Insightful)
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: (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 con
Re: (Score:3, Insightful)
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.
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.
Re: (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: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.
Re:First Column! (Score:5, Insightful)
Re:First Column! (Score:5, Insightful)
By then, it's often too late.
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...
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.
What? You never used continuation columns? (Score:3, Insightful)
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: (Score:3, Insightful)
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: (Score:3, Informative)
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
Re: (Score:3, Informative)
Systems Hungarian or Apps Hungarian? [joelonsoftware.com]
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)
why is this an issue (Score:2, Insightful)
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?
Re: (Score:3)
Re: (Score:3, Insightful)
This is why a code formatter should be part of the source control checkin process.
Re: (Score:2)
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.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
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: (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
Re: (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
Re: (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:why is this an issue (Score:5, Insightful)
Of course (Score:5, Funny)
just stupid, of course we know its plenty.
Re:Of course (Score:5, Funny)
Be Glad You Don't Program Mainframe Cobol (Score:4, Funny)
Re: (Score:3, 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.
Re: (Score:3, Interesting)
The addendum: Width of shuttle booster rockets = width of tunnels - clearance = f( width of tracks) : is also amusing.
Re:It wasn't the VT100 (Score:4, Informative)
The first railway, colliery lines for transporting coal in the UK were pulled by horses.
Re:It wasn't the VT100 (Score:5, Insightful)
Ah the good old days
Re: (Score:3, Informative)
Re: (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.
Additional historical info (Score:5, Informative)
The Other Standard (Score:2)
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? (Score:2)
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 (Score:4, Insightful)
Yes, my spelling of "you're" was wrong twice but (Score:5, Funny)
Re:If your looking for logic in coding conventions (Score:5, Informative)
So in short, 80x25 optimizes memory usage.
Re: (Score:3, Insightful)
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 (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
Re: (Score:3, Insightful)
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: (Score:3, Insightful)
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.
Psychological Thing (Score:2, Insightful)
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.
Re: (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 ge
Modern code. (Score:4, Interesting)
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 ha
Don't count comments (Score:3)
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 (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.
Bad programmers need more than 80 columns (Score:3, Insightful)
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 (Score:5, Insightful)
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 (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() );
If 80 columns ain't enough (Score:3, Informative)
it depends on the language (Score:4, Insightful)
The only problem with 80 columns... (Score:4, Insightful)
words per line and readability (Score:3, Insightful)
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 (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
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: (Score:3, Insightful)
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' (Score:3, Insightful)
Why flat files in the first place? (Score:4, Interesting)
Re: (Score:3, Insightful)
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 { }
Punched cards, baby (Score:3, Informative)
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? (Score:3, Funny)
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 (Score:3, Insightful)
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: (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.
Re: (Score:3, Interesting)