29

In the old days, I remember we were told to never go beyond the 70'th column in the text editor (the actual value was usually something above 70, but less than 80).

Further, at least in the program I was using (the ISPF text editor) against an old mainframe, we also could not use the first three columns as these were reserved for system codes.

If it makes a difference, this was when programming COBOL.

We were never told the reason behind this arbitrary limit; and for a while many modern programming languages also stick to this line length.

What is the history behind this number?

Improve this question
12
  • 20
    @Tommy it's not brainless. There are still good arguments towards keeping text width low, to improve readability and encourage simpler coding styles. I'm certainly grateful that I don't have to read massively long lines since our company adheres to these guidelines. Even if the original technical reason has gone away it doesn't mean there aren't other good reasons for these guidelines to exist.
    – Muzer
    Commented Jun 28, 2018 at 14:09
  • 8
    @Tommy arguments for: Improves code readability, Encourages developers to write simpler code (break up complex statements into logical chunks, etc.) which aids understanding, Improves flexibility for developers working on the code on a wide range of systems (some people like many windows, some people like vertical monitors, some people like large fonts, code might want to be presented in a roomful of people on a projector, etc.). Arguments against: I haven't heard any good ones. So, please do enlighten me.
    – Muzer
    Commented Jun 28, 2018 at 15:11
  • 3
    For: it makes printouts look as nice as the screen. Facilitates code reviews and documentation. Against: requires conscious effort, or a code formatter, or a code editor that supports pinned tabs.
    – snips-n-snails
    Commented Jun 28, 2018 at 15:22
  • 3
    @Muzer I think we're off piste here, but at least we're not on tabs versus spaces! So I'll just say that readability cuts both ways as limits are prone to discourage descriptive naming and function composition, and observe that there is not one natural language style guide in existence that mandates a column limit. Which is strange if it's really an objective readability issue, rather than 'readability' as a proxy for "this is how we've always done it and therefore what we like to read".
    – Tommy
    Commented Jun 28, 2018 at 15:27
  • 3
    @Tommy I definitely agree that it's controversial. I've met many people who don't like it, but I've never had anyone articulate to me why (I mostly just hear "because it's not 1970" as a reason), so I appreciate your points! In terms of natural languages, the style guides of web design often prescribe a column limit (albeit in pixels rather than characters). In fact, the very site we're reading now has a column limit! Reading very long lines is just hard; you're liable to lose your place more. It was your accusation of the adherence to this guideline as brainless to which I object!
    – Muzer
    Commented Jun 28, 2018 at 15:45

6 Answers 6

Reset to default
53

Old COBOL standards were based around 80-column punched cards, and columns beyond 71 (or 72) were reserved for line numbers. They were little used, but a numbered deck, if dropped, could be sorted by a collator.

Because of this, some compilers would not parse beyond a certain column (which could be 70, 71, or 72). So, in the interests of compatibility, it was conventional not to use columns 71-80 for program code. On the system that I worked on (Honeywell Series 60 Level 62), the COBOL compiler would not parse beyond column 72. I no longer have my manuals and quick reference guides, but this IBM web page gives some idea of the various possibilities:

IBM Knowledge Center : Edit boundaries

Improve this answer
10
  • 6
    FORTRAN cards from that era had the same column restriction, and for the same reason. My dad recounted several times when, as a university student in the late 1960's, he accidentally dropped his box of Hollerith cards: fortunately the cards were numbered! Here's a picture of a card with ID columns.
    – ErikF
    Commented Jun 28, 2018 at 7:39
  • 3
    Actually not entirely correct. In the “fixed” (ANSI) source format, positions 1-6 were conventionally used for line numbers. Position 7 was used for a special indicator (* meant comment, / meant form feed when printing source code), and positions 73-80 were ignored and could be used for anything. At one company I worked for, I wrote a preprocessor that uses 73-80 for conditional compilation indicators. tutorialspoint.com/cobol/cobol_basic_syntax.htm
    – mannaggia
    Commented Jun 28, 2018 at 11:23
  • 2
    @mannaggia columns 1-6 were for labels. If you used them for line numbers it might still work (ie. label every single statement consecutively, including comments) but would be confusing for anyone familiar with the langauge, Columns 73-80 were reserved for card sequence numbers.
    – Stephen M. Webb
    Commented Jun 28, 2018 at 13:27
  • 2
    The legacy FORTRAN some of my colleagues occasionally have to fix bugs in, though it's no longer entered on punched cards, still suffers from these compiler-enforced line length restrictions. Any code after the 72nd column is just silently ignored!
    – Muzer
    Commented Jun 28, 2018 at 14:10
  • 1
    I am used to seeing 73-80 used for comments, quite often a reference to the last fix that affected the line. A very old fashioned and simple form of source control but I still see it in use today.
    – badjohn
    Commented Jun 29, 2018 at 10:58
17

In the old days, I remember we were told to never go beyond the 70'th column in the text editor (the actual value was usually something above 70, but less than 80). [...] If it makes a difference, this was when programming COBOL.

No, it doesn't, as it was more of a feature of the underlaying priciples and standards for handling punch cards. By default column 73..80 (*1) where reserved for a numbering. A feature quite handy not only when a stack got mixed up as so often told, but much more when one needs to insert a line (or more) between two existing. Just select a number (*2) between the cards you wanted to insert and voila (*3).

Here also lies the reasoning for using 8 columns. For sure noone back then did belive that there would be ever programms with millions of lines, and especially not 100,000,000 lines. Since the sort was done as (alpha)numeric left to right, it was fine to initial use only 4 digit left alligned line numbers:

0001____
0002____
0003____

Now a line between #2 and #3 could be easy inserted as 00025 (*5).

0001____
0002____
00025___
0003____

Very soon, when Computers featured several KiB of usable memory, compilers became a feature to 'patch' source files. Now all cards of a stack where read and stored in memory before compiling. Lines where sorted in order of their line number durign read (so no more sort run) and when duplicate line numbers came in the newer (later read) line replaced any older (prior read) with the same number (*4).

Now programmers did not repunch the whole program over and over again, but composed a stack of the original programm with all cards added or replaced in chronological order. Only when it started to have more patches than program, or when editing became unreliable (as it relied on the programers memory) a new stack was punched. Again an automated process by feeding the cards into a programm reading and replacing them before outputing to a punch. And yes, that not only mimicks the process, it was a feature of many compilers to read in a programm, do all card processing regarding the 'patch' and then output the source again. Why doing a seperate utility if everything needed is already in place. Our forefathers hated work as much as we do.

In fact, not even the initial numbering had to be done by hand. Already in the pre-computer age it was common to punch cards without a numbering and then run the stack thru a routine that punched increasing numbers into specified columns. Man creates tools.

Further, at least in the program I was using (the ISPF text editor) against an old mainframe, we also could not use the first three columns as these were reserved for system codes.

Now that is unusual and may be system specific. There are in general five general formats for punch cards:

  • Application - column 1..80 to be used as needed

  • Standard - 1..72 is used for content, 73..80 is used for numbering. This was first widely used in Assembler and FORTRAN and became the standard for the IBM world

  • Assembler - 1..71 is used for content, 72 for continuation and 73..80 for numbering

  • COBOL - 1..6 is used for numbering, 7 for continuation

  • IBM Cobol - Like COBOL, but in addition column 73..80 is again reserved for IBM standard numbering

The last case shows a nice dilemma between a languages standard and a system wide standard. As a result COBOL compilers could be set to use either number - or check them for having the same value (*6).

Less related, for later variable length formats the sort/numbering column ent int the first 8 characters. Still the big old three, Assembler, COBOL and Fortran, did keep the ability to work with fixed length.

*1 - Columns on a punch card are numbered 1..80, not 0..79.

*2 - The 'numbering' didn't have to be numbers as it was taken as an alphanumeric sort field according to the numeric value of each char. Later on, in memory sort used the full EBCDIC value.

*3 - And thanks to card sorters one didn't have to look for the right loction to slip in the card(s). Lust add them to the stack and run your (up to) 8 sort runs.

*4 - Deleting was done by adding a card with the right line number and no program text.

*5 - It was a good idea to use a number somewhere inbetween to leave room for more line numbers. Then again, I once knew a guy who used to go just by one. So the line between 1__ and 2__ became 11_ the next insert was not 12_ but 111. Easy to see where that was going, right? No, he did ran into that problem over and over again :))

*6 - something that also happened with at least one Mainframe BASIC.

Improve this answer
2
  • 1
    Much of this line numbering philosophy later found its way into BASIC. It was common to initially number your lines with increment of 10, then you could insert new statements with numbers in between, and when it got too crowded there was a RENUM command that could be told to regenerate the by-10 increments.
    – Barmar
    Commented Jun 28, 2018 at 17:14
  • @Barmar, renum was a pretty advanced feature, I remember implementing it for some BASIC (TRS-80, maybe?). It mostly worked except for when you had computed goto statements like goto optn * 1000 + 9000 :-)
    – paxdiablo
    Commented Jan 29, 2023 at 13:09
17

On the basis that a picture is worth a thousand words, I include my scan of a punched card:

enter image description here

As amply described in the other answers, it shows how the columns are visibly marked on the card for different purposes. It makes sense when you see a card. It makes less sense when you're using a computer display or are using paper tape!

Improve this answer
10
  • Yeah, tab-stops on a picture of a display are hard to see :)) Also, paper-tapes never played a role on mainframes - that's a thing of cost sensitive minis - which developed years after these column standards became such.
    – Raffzahn
    Commented Jun 28, 2018 at 17:19
  • @Raffzahn Correct that paper tapes were much more of a minicomputer thing, not mainframe. But the technology of paper tapes goes back to the 19th century (along with punched cards). Not sure exactly why, though one reason may be the interactive nature of minis vs. batch mode of mainframes, at least in the early days.
    – manassehkatz-Moving 2 Codidact
    Commented Jun 28, 2018 at 18:55
  • @manassehkatz It may have been more abudget issue. Mainframes where usually installed in a working punch card environment - or at least came with all neccessary punch card equippment available - and a well defined tool chanin around punch cards. Minis in contrast grew in a quite cost constrained envirionment. In laboratories and departments happy to afford the CPU, and no money to buy punchers, sorters and readers. So cheapteletypes and connected punch tape it was. Further there wasn't the same need for high thruput punch cards offered.
    – Raffzahn
    Commented Jun 28, 2018 at 19:08
  • @Raffzahn All true. But I also think in terms of minis being the typical teletype-as-main-access point type of system. So using the tape punch/reader as part of a teletype is a natural extension and doesn't take away from the interactive nature of the system. Whereas punch cards were strictly a batch mode process - even if you sat at a keypunch to type up a program (which I thankfully just barely missed having to do when I was at Univ. of MD in the 1980s) you HAD to use a different device to actually input the cards into the computer.
    – manassehkatz-Moving 2 Codidact
    Commented Jun 28, 2018 at 19:18
  • 1
    @Raffzahn: I wonder to what extent paper tapes became popular with minicomputers because they were built into teletypes like the ASR-33? Even if a system has a disk drive, the code required to fetch and execute a block from disk may be over a hundred bytes. Entering that code using panel switches may be rather a nuisance. By contrast, a loader to receive a hundred or so bytes from a serial port can be under two dozen bytes. Entering that from panel switches, and then having a program on tape which boots the disk may be much more convenient. Even if the tape operates at 110 baud...
    – supercat
    Commented Jun 29, 2018 at 15:47
2

Punched cards were, of necessity, a fixed number of columns (80, with fixed column use dependent on the language. JCL, for example, used the entire card). Many programming languages introduced at that time had a fixed format in which the column a character appeared in was significant, much like the invisible significance of position in modern programming languages such as Python today. Language constructs could span more than the fixed number of characters usually by having a special character appear in a specific column, known as a "continuation line."

When things progressed to using video display terminals, they too had a fixed number of columns, and by no small coincidence the number of columns (80) tended to match the number of columns on a punched card. In fact, VDTs were sometimes referred to as "glass keypunches."

Along comes the more recent decades with better display technology and free-format programming languages with context-free grammars. These are better times and we are less constrained by the media and the limits of technology. Turns out that we are actually limited by our feeble mortal bodies and that centuries of accumulated wisdom on the presentation of textual information is starting to come around again. The art of compositing text, developed by ancient monks and scribes and refined by printers from the 12th century onwards tells us that our physical limitations mean we can better read and uderstand narrower columns of text with a half-ragged edge (for left-to-right text, a justified left and a ragged right). Columns somewhere around 80 columns wide. I think it is no coincidence.

Improve this answer
1
  • And yet, even on modern mainframe, you generally create datasets with fixed record sizes. This was the hardest thing to get used to (record sizes, extents, and so on) when I entered the mainframe arena after having been forged in the UNIX world. Of course, that's only on the MVS side of z/OS. The zLinux side looks no real different to Linux itself in terms of file layout.
    – paxdiablo
    Commented Jan 29, 2023 at 13:12
1

I an not answering with certainly (because it was not be making the decisions), however I have given 4 factors that are relevant. With a focus on making the decision today.

There are at least 4 reasons, however the people that came up with the rule may have only been thinking of the technical reason, and not discovered the others.

  • Technical reason: something to do with punch cards or monitors or … (see other answers, they can explain this better than me).
  • Typography: Typographers have known for a long time (much longer that the 80 character standard) (200 years for the printing press, and longer for hand written texts), that texts, with more than one line, and with long lines are hard to read. Therefore you should have a single very long line (the cost of finding the start of the next line is very high, but there is no next line), or have multiple lines that are short, probably limit to < 60 characters.
  • Long lines of code tend to be more complex, therefore it is better to keep them short.
  • long lines will wrap as some arbitrary point, on someones screen. Thus making it hard to read. Therefore put in line breaks where they make sense.

The 2nd and 4rd rule are still relevant, however they are not hard limits, as is rule 1. Therefore use them as a guide.

Improve this answer
3
  • 1 - As noted, already explained (extremely well) above. 2 - TOTAL RUBBISH! 3 - If the complexity is needed, it is needed, and then short line limits result in wrapping, line extension chars, etc. Programs are complex. Live with it. 4 - That is a description of how to decide on a large screen where to break lines, it has nothing to do with how/why/history of specific screen sizes.
    – manassehkatz-Moving 2 Codidact
    Commented Jun 29, 2018 at 14:09
  • 2
    @manassehkatz - I don't know why you say the second reason is rubbish. The proper line length in texts is very well studied. If the line is too long readers have to slow down to get back to the beginning of the column. The general rules of thumb seem to favor line lengths in the range of 40-80 characters per line. See: Graphic Design StackExchange and Wikipedia - Line Length
    – Kyle A
    Commented Jun 29, 2018 at 15:03
  • 1
    I agree on 40-80. But you wrote "Therefore you should have a single very long line, or have multiple lines that are short, probably limit to < 40 characters." which is quite different.
    – manassehkatz-Moving 2 Codidact
    Commented Jun 29, 2018 at 16:59
-1

FORTRAN was first released for the IBM 704; the 704 used as input the IBM 711 card reader.

The 711 could only read 72 columns of an 80-column card, and that's why FORTRAN statements had to occupy columns 1 to 72.

https://www-03.ibm.com/ibm/history/exhibits/701/701_1415bx11.html

Naturally, this hardware limitation became enshrined as a standard.

Improve this answer
2
  • Sorry, but that feature is not related to Fortran in any way, or regular punch cards at all. This 72 column mode is a special binary loader format. The 704 memory was organized as 36 bit words, and each ROW of a card in this format cound therefore hold two words in binary. Source text was punched in standardformat with one character per COLUMN.
    – Raffzahn
    Commented Jul 31, 2018 at 2:57
  • I believe the 711 reader itself is limited to reading 72 columns. There are a full 80 columns of reading brushes, but only 72 columns worth can be transferred to the computer. The 701 Principles of Operations manual (bitsavers.org/pdf/ibm/701/24-6042-1_701_PrincOps.pdf) on page 35 says that the 711 always transfers row-wise (one row = two words) to the 701, and if the intent is that the card is punched with decimal, alphanumeric, etc., data, then software in the 701 must translate. The 711 appears to have no buffering, so it's limited to transferring data as it is read.
    – dave
    Commented Aug 1, 2018 at 2:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .