Worst… Code… Ever…
Like many developers, we enjoy making fun of other people’s code. I’ve had lots of those discussions over the years. And when it comes to who has had to work with the worst code, I’ve never lost.
Way back when I was just out of college – when 7-bit ASCII ruled the world, and people hadn’t decided whether lowercase characters were a fad or not – I worked for a Large Seattle Aerospace Company, at Large Seattle Aerospace Company Computer Services, in a group that built graphics tools for engineers.
One of the libraries that we owned was generated code.
Now, I don’t hate generated code. The Windows Forms Designer and I have a generally felicitious relationship. I even have a patent cube (which you get when an application is accepted at Microsoft) sitting on my windowsill that is related to an architecture for doing generated code.
This particular library was special. It goes without saying that the source to the generator was lost in the card recycling bin of time, but that was not what made it unique.
First of all, it was in FORTRAN. And not that namby-pamby FORTRAN where you can have modern control structures, this was FORTRAN 77, and you had better know how to count spaces and what it meant to put a character in column 6. Did you think that python came up with the idea of significant whitespace? Pshaw.
Secondly, the programmer who had written the code generator was a bit of a FORTRAN afficianado. There’s a feature in FORTRAN 77 known as the “assigned goto”. Here’s an example:
ASSIGN 30 TO LABEL
NUM = 40
GO TO LABEL
NUM = 50 ! This statement is not executed
30 ASSIGN 1000 TO IFMT
PRINT IFMT, NUM ! IFMT is the format specifier
1000 FORMAT(1X,I4)
END
Now, to understand this, you have to remember that by default, any variable that starts with the letters I-N is implicitly an INTEGER variable (all others are implicitly REAL). So, you can assign 30 to LABEL (this is *not* the same thing as writing LABEL=30, which means what you expect it to mean), and then use “GO TO LABEL” to goto 30.
Suffice it to say that the developer had never read Dijkstra.
Now, my guess is that while the vast majority of you are thankful that you don’t have to work in FORTRAN, there is a divide in opinion beyond that. Some of you are saying “Well, that’s not really that bad”. But the rest of you are shaking your heads, because you know what is coming.
When you’re doing code generation, you need to somehow come up with variable names. In this case, the developer took the easy way out, and all integer variables were something like “I1344”.
And line numbers also use the same range, starting at 1000 and going on up.
So, it means that the code has lots statements like:
GO TO 11634
and lots statements like:
GO TO I1655
Did I mention that in the fonts of the day, the difference between “1” and “I” was fairly subtle? Even if you did notice the I in front, you had to cope with the fact that
GO TO I1655
really meant
GO TO 3455
At least, it meant that sometimes, but I1655 would be re-assigned when the program ran.
IIRC, there were about 15K lines of this in library.
So, bother me not with tales of poorly-formatted C# code or 2000 line C functions. They are mere trifles. To snatch the rock from my palm will require something stronger. Are you up to the challenge?
(I am a bit worried that there might be some LISP or APL programmers out there…)
Recent Comments