Today's xkcd brought back the memory of my very first consulting job. It was a Pascal thingy, a graphical thingy to display icons and stuff on some maps, on
DEC windows - I think that's what it was called, some flavor of X, running on whatever their
unix of the time was called. This was in early alpha days, the hardware was cool and very expensive.
Pascal was not so cool, at least not in my eyes. I don't really remember such things now but unless memory deceives, Pascal used to be one-pass and all the code had to be in a single source file.
For those who haven't tried it: API level graphics programming is structurally speaking one of the more complicated and counter-intuitive types of programs. It requires the program to be laid out in a certain way, or chaos ensues. In case you haven't figured that out yet, in this program, chaos had taken over long ago. I've never seen an attempt to write a graphics program of the event loop era that didn't follow the same basic layout - except this one. It's really hard to explain how wrong this is.
Since it had to be contained in a single file, the file had grown to around thirty thousand lines. That's not a huge program, by any stretch, but for a single package of information it's a little too much. Good thing Pascal is a structured language, it could all be divided into separate procedures so there'd be some chance to find one's way around it, right? Well, there were procedures. Four of them. That thirty thousand line file was split into four procedures.
To be perfectly honest, it might have been six procedures, I forget. It really didn't save this program.
Have you ever written code? If you've had any formal training, you know that the most important thing to learn is how to structure program flow and control. Back before structured languages, programmers had to used a thing called goto - the code was one huge pile of instructions and flow was directed with these goto statements. In the late 60s, Dijkstra wrote "
goto considered harmful", which must be considered one of the milestones in the history of computer programming. Over the next decade, using goto became increasingly taboo. Well, nobody had told the writer of the program I was looking at. It had gotos everywhere. Programmers often use the term spaghetti code for something that is convoluted and tangled up - like a pile of spaghetti. This was the worst case of spaghettification I had ever seen, and it still is. The code was littered with goto statements and the destination labels, the places where goto statements where directed from other places in the code, were just as many. It was one of those horror movie moments where the protagonists stare, wide eyed, into the camera and shout
Oh my god, they're everywhere!
Have you ever written a Pascal program? The Pascal language is quite old, and it was defined in an era where compilers were a lot simpler so the coder had to follow a bunch of rules. The rules were sort of sensible if you think of it as if the language and compiler had been constructed from scratch, which while not entirely true still isn't a bad picture of the level where software existed at the time. One of the rules was that each procedure has to have all its variables declared in a special section at its top. Keeping that section nice and tidy usually isn't much of a problem since there are usually only a few variables to declare - call it a dozen or so. In Pascal, they will have to be on a few separate lines since different types of variables each require their own separate lines. It's rather unusual for that section to be more than, say, three or four lines.
Not so this program. In this program, each procedure had a variable declaration section that was a whole screenful of text. That, in itself, could have had a rational, sane explanation. All those variables might be needed for some reason - I doubt there'd be a good reason, but there might exist a reason, some sort of explanation. I do understand how all those dozens of dozens of variables got there but in this case, I refuse to call the explanation "a reason". It would be too flattering.
This programmer didn't believe in descriptive names for variables (or anything else - since there weren't many procedures enough to matter, that wasn't really the problem, but this was really just one fault hiding another). Programmers often find that they need a variable just for moment, they create a variable to store a value and almost immediately they retrieve the value and the variable is never used again. Such variables sometimes get names that don't do anything to explain their purpose. Programmer culture has a whole gamut of such names: foo, bar, baz, ble, gazonk, the list goes on. While code in Swedish settings is mostly written in English, sometimes it's in Swedish and there are a bunch of frequently used metavariables in Swedish too, though they tend to be real nouns instead of the nonsense of the English ones. I'd guess the most common ones are gurka and bulle. Of course, there was also no documentation and the code contained no comments.
So this code was written by someone who didn't know, or didn't care, how to write code that did a certain type of job, that was possible to maintain or improve, or that was was understandable. As this programmer needed a variable, guess what he called it? Of course, first he used the common metavaraibles. There would be a foo and a bar among the first variable names. Then there'd be foo2 and bar2 as he needed more. Eventually he'd run out of those names and resort to the math style variable names, i, j, k, l, r, s, m, and then he'd double those and then he'd number them. After using ii and mm2 and a couple dozen such names, he'd move on to Swedish words; gurka and bulle, and of course, gurka2 and bulle2 soon followed.
But that wasn't enough. So he resorted to four letter words. Any grown up person wouldn't use those words for variables but I guess he just got really, really tired of thinking up those name. I felt sorry for him and the program he made when I saw those variables declared. Anything that contains penis2 just didn't get a fair chance.