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

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.

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?

If your looking for logic in coding conventions

[ClosedSource]

your looking in the wrong place.

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.

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.

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.

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

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

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

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.

Re:If your looking for logic in coding conventions

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

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

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

Legibility

[superbrose]

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

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

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

looks better on one line than writing:

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

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

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

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

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.

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:Computer Formatting vs Automation

[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..."). But you forget about the mass of details a program has. UML describing all this WILL get messy and tedious to maintain, more so than a traditional programming language.

Standard Paper

[Anonymous Coward]

Until they change the standards for paper (8.5x11 US and the equivalent A4 size) this about the best size. At 12cpi (10 pt), you can read it without squinting a lot and put one complete line of code on one line of print while leaving some space for punch holes (putting into Notebooks). I know MANY people who find printed easier to work with and since most lines are short ( i++ in C for example ), using Landscape orientation is a waste of paper. As for the "paperless office", forget it! Laptops do not have power for extended periods of time without a plug whereas paper does. And marking up (arrows, commect the "dots" in figuring out codes etc.) is not nearly so easy on a CRT even if the CRT (and especially LCDs) did not strain my eyes. When we get a reasonable replacement for printed material, then....

No 20/20 vision here!

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?

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!

[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: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!

[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 wide editor and try to read it; it's a PITA compared to reading a narrow column.)

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.

Michael

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!

[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:why is this an issue

[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: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:Nah

[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. Letting tab width be different from indentation width and using some "smart indent" feature to replace with tabs... I mean, it wreaks havoc on anyone trying to read it with another tab size. Either only use spaces, or only tabs. :-)

Re:Why flat files in the first place?

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

You're using too many levels of indentation.

[Anonymous Coward]

If you're using 5 or more levels of indentation, your code is too complex.

That's a nice little side effect of enforcing an 80-character line length limit - you can't get away with writing code that's too complex.

Re:First Column!

[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't, then the lining-up can't be maintained by other programmers' tools, which means it would be a pain in the ass for other people to keep that special indentation. In such cases you should give up on special formatting rather than create visions of perfection that other people can't maintain.

It's best to write code that doesn't need special formatting to be readable. You should be able to run your code through *any* sufficiently good code formatter or indenter and have it end up readable. If that isn't possible, forget about "fixing" other programmers' fonts and tools; fix the code.

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!

[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:Nah

[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 spaces into file.)

Just resign yourself to the fact that nothing works, because people are lazy and dumb. Trying to outsmart the problem is never works, because people are lazy and dumb.

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.

Not arbitrary

[Anonymous Coward]

Typographers agree that 65-70 characters is about the maximum size that one can read comfortably in printed material without having to readjust eyes when skipping to the next line. In 80-column cards, the last 8 columns are usually reserved for identification, and old Fortran uses the first 6 columns for line numbers and continuation control.

So we get 66 characters of payload in listings, pretty much the optimum. 80 columns are quite sensible for programming purposes for that reason, at least when we are talking about the readability of filled comment blocks.

For programming languages and styles which make excessive use of indentation, the remaining payload is quite less. However, keeping track of the nesting also becomes more complicated when one excessively nests things.

Re:First Column!

[Anonymous Coward]

The good thing about sticking to 80 columns is that on modern screens/usual font sizes, you can stick two editor screens next to each other. So whatever new column width people come up with should consider that scenario, because it's so damn useful I really don't want to give it up. Yes, it's all about me.

The column width I come up with when I consider that requirement, my screen and font sizes, etc, would be 94 columns. Can everyone fit two files on the screen next to each other at 94 columns?

Re:First Column!

[Anonymous Coward]

agree w/ u; down w/ wide txt!

Actually, no I don't. I'll take verbose over pointlessly terse text any day.

Re:First Column!

[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. I indented 3 spaces, my maximum identifier length was 15 characters, my max argument list was 3 parameters, my methods were short, and my maximum indentation level was 3 (excluding the class and method indents). I do use abbreviations, such as CancelBtn for CancelButton, but I think these are pretty obvious and I use them consistently throughout the code.

I know some programmers (good ones) who go into their IDE and maximize their window. And they can't even split their window. If I work with them, I actually start to feel claustrophobic looking at their monitor. I guess everybody has a different working style.

Re:First Column!

[LeadSongDog]

Most of these whippersnappers have never even seen a Hollerith card, let alone understood how utterly dependent the world was on them. Programmers lived in terror of the day the dropped their card deck. "Do not fold, spindle or mutilate" was the eleventh commandment. See http://en.wikipedia.org/wiki/Punch_card [wikipedia.org] to get a clue.