See if you can decipher this one free-form example (courtesy Paul Henning):
integer function end(return,&
integer)result(function);;;;&
integer integer,return;;;;;;&
;;function=return;if(return>&
integer)return;;;;;function=&
integer;;end function end;;;;
Here is another one for fixed-form (I invented this one):
integerfunctionfunctionf(n)
integerfunctionfunctionf(n)
integern
endfunctionfunctionf
Not exactly cryptic, but my two āfavoriteā fixed vs free form anomalies I encoutered in a Sandia fixed form Fortran code (still in use and comprising close to 500K lines of code) were
Someone thought it was jolly fun to put a space between letters in keywords (namely)
S U B R O U T I N E or F U N C T I O N
This caused a tool I wrote to convert from fixed to free form a lot of gastric distress
and
ie Data /a/ā¦1.234 ā col 72
col 6ā> +5678
You normally see these kinds of things with codes that have been around for decades, had several people contribute to it, and no one is providing any adult supervision in the form of rigidly enforced coding standards and practices.
I learned recently that the reason spaces were allowed is because it would be inconvenient if you had to repunch a card in case of a mistake.
Yes but this particular part of the code was written after key punches were a thing of the past. It was just someone (probably a novice post-doc) who probably thought it was more āreadableā that way. BTW I started my Fortran programming journey with punch cards. In my first real engineering job, I was responsible for implementing the Space Shuttle ascent and on-orbit guidance and control algorithms in a simulation code NASA used to do trajectory design and mission planning. One day I sent several boxes of cards over to the central computing facility at JSC were they were read into a Univac 1108 system. The next day I got my listing back and I had exceeded the maximum number of errors allowed by the Univac Fortran compiler. Turns out a kid hired for the summer to feed the card readers had dropped a couple of boxes but decided to feed them into the reader anyhow because they thought the computer would figure it all out. Thankfully, the cards all had sequence numbers in cols 73-80. Although cards could be a pain, I kind of miss those days because I would write the code on a āgreenā sheet, give it to our company key punch operator and then go do real engineering work. These days with interactive editors, etc. I find I sometimes get to caught up in just creating the code and the real engineering work takes a back seat for a while.
For those too young to know what a āgreen sheetā is. Here is an example. For some reason I still have a pad of forms in my archives so Iām prepared when punch cards make a comeback. Hey if it can happen with vinyl records why not punch cards 
Some lines and sharpie pattern across the sides of the cards ā similar to the picture below ā were a popular approach to keep the stacked cards in correct sequence.
(image credit: University of Washington)
Lending a hand to vacate a room for new installations, one of the boxes was like this one. According to the seniors, only once a day was a possibility to submit a stack to the computing centre, so the additional rubber band was a usual thing. (Beside, the elders became highly attentive to spot syntax errors prior to sending the stacks out.)
Punch cards are great, I think it is more durable to store source code on paper in āanalogā form. I still have some code from 30 years ago on floppy disks, and I doubt I could read it. I then found a printout of some code from the same time on paper and that is perfectly readable.
What is the most efficient way to store programs on paper?
The most robust, but low density, is probably just printing it with some high quality font.
The highest density can be achieved with something like a QR code. Here are some links for some formats that seem higher density than a QR code:
They often also put some error correction in it, which relates to robustness of reading it back correctly, but reduces capacity.
In the GitHub Arctic Code Vault short-movie, they mentioned using archive-quality silver-halide film which is meant to last about 1000 years. The 21 TB of data was imprinted on 186 archive-quality film reels, encoded as QR codes. According to articles I could find a company called Piql provided the service.
I recently had a company get all my old college programs code off a set of 40-50 year-old 1/2-inch mag tapes for me. I was overwhelmed that they could extract it at all.
It was important to get a good severe angle on the lines. You didnāt want ambiguity when comparing two cards you were picking up off the floor.
@ivanpribec thanks, I think this is the state of the art technology how to do it. Iāll see if I can find out the resolution of their QR codes. I would be very interested in doing the same kind of state of the art, but using a consumer printer, so it would have to be larger resolution. It would also be nice to āscanā the whole page using a phone, that would make it very easy to use. I would like to use todayās printers to print it (probably in color, to increase data density), with the property that if the very paper that I print today, was somehow stored in the attic in 1990, I could immediately read it using my phone today (30 years later). So if I print it today, I want to be able to read it in 2053.
@gak nice! You should upload your 50 year old code to GitHub. 
Already there in a private repo. I sent you a collaborator invite. Most of it is ancient PL/I, System 360 assembler, some Algol-W, and Pascal. Lots of stuff from my student days. Thereās also a Basic interpreter that I sold to get the down payment on my first condo.
