At some point in the past, around the 1970's or so, programmers wrote their code on paper. Considering the fact that modern computers have replaced paper in so many ways, the whole idea seems a little backwards.

I have no first hand experience with these things. I have a vague idea how it worked, but I want more details. I assume that the process is similar to filling out regular paperwork, but the fact that these were programs that had to follow a complex syntax must complicate things a little.

Obviously, these programming forms couldn't be fed directly into the computer, so something had to be done to put it in machine readable format.

What needed to be done to actually run a program written on a form? Was this an error-prone process? In this one book I have, the format on some of the programs is a little lax:

it's a big image... Photo mine. It's a COBOL book.

Near the top, some lines are crossed out. But near the bottom of the page, some of the code is literally outside the lines: it's straddling two lines.

Here's a full example of a form:

Coding form https://commons.wikimedia.org/wiki/File:FortranCodingForm.png

  • 9
    Tsk, tsk. You are mixing Cobol and Fortran forms. ;-) That's how you get on the Data Entry department's bad side. May 27, 2016 at 14:47
  • 3
    "At some point in the past, around the 1970's or so, programmers wrote their code on paper." Not only did we write then on paper, we bench-tested and debugged them on paper, by hand first. Because that was much faster/more efficient than waiting for execution submission turnarounds. May 27, 2016 at 14:49
  • 2
    The straddled line section isn't meant to be sent to data entry. This is documentation showing two alternative printing options - for the voucher line or the check line. May 27, 2016 at 16:38
  • Long time ago... For us it was RPG, Report Program Generator. There were 5 or 6 forms, input, output, calculation and report, if memory serves. I think there was a couple more, although they were seldom used. The input was very structured and submitted on punched cards. There were some surprisingly complex programs written with thoses funny forms. Thanks for the memory.
    – Appletrain
    Jun 1, 2016 at 0:26
  • 1
    I was still paper coding in the late '80's... 20-30 students for each available microcomputer meant you wrote and debugged on paper. Computer time was VERY hard to come by! Jun 24, 2016 at 20:04

3 Answers 3


Coding forms such as your examples are basically just really fancy lined paper. The fixed grid is there to help you organize your code and reduce errors when you (or a clerk) actually type in the code, but it still needs to be manually entered.

Your completed form would go to someone operating a punch card machine or interactive terminal so that all your time spent thinking and reworking the code didn't tie up the limited computer resources. As for drawing outside the lines, this would just basically make the data entry a little more error prone if whoever doing the keying interpreted things incorrectly.

Finally, the completed code form would be retained and serve as basic documentation for the program, since the final entered code wouldn't be human-readable. Any reworks to the code you needed to do, you would refer back to the code form first.

I should probably also mention that even up until the mid-90s forms like these were still being used in the teaching of certain languages such as COBOL, despite the prevalence of adequate numbers of interactive terminals, in an effort to impress upon students good documentation habits and in case they happened to land a job at an organization that still required that level of formality.

One other thing, the code form wouldn't be your first step in starting to write a program either. You'd typically start by getting out your flow-charting stencil and drawing out a flowchart for the program logic before writing any code on a form to make sure you understood what the program needed to do and how it was going to do it. Flow charting in this manner was definitely something still being taught in the mid 90's also. When I attended college in '95 one of my first year courses was a "Programming Logic" course for which the coursework consisted mostly of coming up with answers to programming questions in hand-drawn flowchart and then writing out the code from that in pseudo-code form without touching a computer for the entire semester in that class.

  • 1
    So what would you do if the data entry got messed up?
    – Laurel
    May 26, 2016 at 20:49
  • Check the code form first to make sure the error wasn't in the program logic and look for any irregularities that would be likely to cause a miss-keying (forgot to cross your zero, so maybe they thought it was an O, etc). Assuming you didn't find anything wrong there you'd either have to have it re-keyed or actually look at the machine-readable program (punch cards, etc) and try to locate the error, as a last resort.
    – mnem
    May 26, 2016 at 20:53
  • 1
    Yes. You filled out the form, which had 80 columns, like a Hollerith card. Each line in the form was typed (by a data-entry person) at a keypunch machine to punch one card. Certain columns of the form were sometimes shaded to indicate their use in a particular language: column 7 for a continuation column, columns 72-80 for comments. When you wrote on the form you had to take care to use uppercase "I" with top and bottom serifs for the letter "i" and a single vertical stroke for the numeral "1". Similarly, a diagonally barred zero for the numeral "0" and an uppercase "O" for the letter "o".
    – Drew
    May 27, 2016 at 2:05
  • 4
    Even if you keypunched your own cards you typically wrote the program out on such forms first.
    – Drew
    May 27, 2016 at 2:06
  • 7
    Another reason that companies used dedicated card punch personnel is that they were recruited from the typing pool. They could operate a keyboard very quickly, while programmers were not then expected to be so quick. The higher paid programmers could spend their time programming, not typing..
    – Chenmunka
    May 27, 2016 at 7:25

Some computer languages had a very strict syntax. COBOL, which is the language featured in your pictures, is a good example of this. The language only allows code to be entered from column 8 or 12 (depending on if it is a division, or a section). Column 7 was used to mark the line as a comment (by using an asterisk, AFAIR), and so on. FORTRAN, which is the language the second form you feature is for, uses the character C (in a specific column if I remember well) to mark the line as a comment.

Why? Several reasons. Among them:

  • Simplifies the compiler and the compiling process: by forcing source code to follow strict indentation rules, the lexical analyzer is much more easy to write and thus needs less memory and executes faster. Remember that memory and computing power were scarce resouces back in the day.

  • Force the programmer to follow a programming style that may help him to quickly find bugs. Specifically, COBOL was designed to be understable for non-programmers (bankers are not very comfortable not knowing what a computing nerd is doing with his money, so they needed a computer language that they could understand)

  • Such forms were needed as a previous step, to later make punched cards from them. COBOL, for example, had more restrictions to suit punch cards, such as the maximum length allowed in a line (72 chars if I remember well). These restrictions were in part forced by the fact that each line in a COBOL programming form had to be encoded onto a punched card, each character into each column, and with a maximum of 72 columns (this is from memory). The special column to mark the whole line as a comment is a needed feature to speed up the process of entering the computer program from a punched card reader: the reader could just throw away the whole card if the special column is marked with the comment character.

  • This answer made me realize that the book I have doesn't ever use the 7th column ("CONT"), and doesn't explain ANYTHING about code comments. Instead, the form has a right margin where it expects you to put your comments.
    – Laurel
    May 26, 2016 at 22:49
  • I guess coders used both formatted commentaries and informal commentaries. The former would be used also to easy separate different stacks of punch cards. Take into account that there was probably a line printer that would make a hard copy of your program, as it was entered, so you could see what the computer is actually executing, in case there is a mismatch between what you have in your form and what the computer has understood. May 26, 2016 at 23:00
  • My dad actually still does COBOL programming for a living (it's his book), so I asked him. He said that it's a really early version of COBOL (it doesn't even have ELSE statements). The 7th column is used for a line continuation in this case, but later on I think it was used like you said for comments.
    – Laurel
    May 26, 2016 at 23:28
  • The 7th, CONT, column was used for FORTRAN. It indicated that the card was a continuation of the line above.
    – Chenmunka
    May 27, 2016 at 7:19
  • @Chenmunka On closer inspection of the FORTRAN form, I see that it also has a CONT. column, but it's the 6th one. If you look really closely at the COBOL form in my picture, you can see that it actually says CONT too (and it's the 7th column).
    – Laurel
    May 27, 2016 at 15:19

I still have some of mine.

The answer, for most large organzations was that you submitted them to the Data Entry Operators who would key them in to make punched cards for you (or for smaller organizations, or if you were a lowly intern, you keyed them in yourself).

Then you would take your program in the form of punched cards (called a "Deck") over to the Operators who would load it and schedule it for execution. Hours or days later, you would receive a fan-fold printout of your programs execution and output.

  • 3
    You got the program's output if you were lucky. Usually you got the assembler's or compiler's error listing the first few times. With developer's jobs scheduled around the production work, you had to have several projects going simultaneously if you weren't to sit around waiting for your printouts. May 27, 2016 at 16:32
  • @DavidMarshall Yep. May 27, 2016 at 17:09

You must log in to answer this question.

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