Don’t ever be ashamed of your code
Are you ever ashamed of your code? Don’t be! Being ashamed of your code is harmful, as artfully explained by Ben Collins-Sussman. It’s better to make your mistakes in the open where they can be quickly corrected than in private where they can fester for months, even years. Note that we aren’t necessarily talking about open source code here. Being ashamed of your code could also mean not sharing code with other people at your company.
Ben uses some anecdotes to illustrate just how badly situations can get when programmers (or small groups of programmers) sit on their code for months on end without any outside sanity checking whatsoever. But these anecdotes are more humorous than necessary, as it’s pretty much a truism in computer science that coding off on your own in secret is a bad idea. The people who are doing it know it’s bad, and the only reason they persist is because they are ashamed. Oftentimes they’ll rationalize it by saying “I’ll just clean it up before I let others see it” — which, when combined with procrastination, can mean no one else sees it for months or even years. And if poor architecture decisions have been made, as they often are, the problem is too large for a simple clean up; a partial or full rewrite is necessary. This is not the situation you want to find yourself in.
Luckily, I can’t say I’ve ever felt ashamed of my code. And that’s not for lack of writing some truly terrible programs, either. I just value the feedback I get from others more than any personal attachment I might have to my code. In other words, I don’t take it personally. And to demonstrate that, I’m going to post a truly terrible program I wrote back in high school. My only excuse is that I was young and ignorant.
The program in question is “makeSite”, a program I wrote to create my blog-like website before the word “blog” even existed and before any real blogging software had been developed. I was writing what was effectively a blog at the time (you can see an archive of it here), but I got tired of having to hand-edit the HTML to copy over a previous entry and modify it each time I wrote a new entry. So, naturally enough, I wrote a C++ program to statically compile a bunch of text “data” files containing my own custom pseudo-HTML-like syntax into a website. I won’t defend the decision to do it this way, other than to say that I didn’t know any better. What this effectively meant was that every time I updated any part of my site, even to fix a one-character typo, my entire site had to be re-compiled by re-running the program, a task that, because my program wasn’t very efficient, was taking minutes after my site grew to be rather big. I toyed with the idea of some sort of incremental site compilation, only updating the pages corresponding to the changed data files, but I never got that working.
I think it’ll help to illustrate how bad this program truly is by individually discussing some of the more egregious parts of it.
#include “apstring.h”
For those of you who aren’t familiar with the “apstring” string library, here’s a hint: ap stands for Advanced Placement. That’s right, instead of using a standard, widely used string library (like “string.h”), I used the apstring library (by the College Board), because that’s what we were taught in class. It was just like a real string library, only it didn’t have as many features. Frankly, there’s no excuse for its existence, as tests should conform to reality and not the other way around. If you ever see it in production code, you should run like hell.
headFile.open(“pages.dat”);
output.open(“pages2.dat”);
while (headFile.get(ch))
output << ch;
output.close();
headFile.close();
Yes, you really are looking at a character-by-character copy of a file. Never mind that there's an OS function to do this in one line (and much more efficiently, I might add). But the reason I did it this way is even worse than the way I did it, if that’s possible: I wanted a second copy of the file so I could parse through the original string-by-string, and then when I hit upon a page that was a subpage of another page, I would consult this copy to find out what its parent page was. This was to get around the problem of not being able to have two file handles open to the same file. I suppose the concept of just loading the whole file into memory and parsing through that didn’t occur to me. And notice the hard-coded file names; that’s a nice touch.
if (temp1 == “
if (temp1 == “
invisFlag = false;
else if (temp1 == “
invisFlag = true;
headFile >> rootPage2;
getline(headFile, temp1);
if (!invisFlag)
column = column + “![](\"bullet.gif\")
” + temp1 + “
\n”;
}
else if (rootPage2 == rootPage && !invisFlag) {
getline(headFile, temp2);
column = column + “![](\"arrow.gif\")
column = column + rootPage2 + '_' + temp1 + ".html\">” + temp2 + “
\n”;
}
This spaghetti code just screams “I was hacked together over an extended period of time!”. As I added more functionality, I didn’t do any refactoring; I just kept adding more conditionals and more flags. I also award myself bonus points for using such amazing, descriptive variable names as “rootPage” and “rootPage2″.
toReturn += “
| \n”; if (torpg) { toReturn += “ ![](\"bar_top_left_torpg.gif\") “;toReturn += “ |
“; toReturn = toReturn + “ ” + temp;
toReturn = toReturn + “ |
![](\"bar_right_torpg.gif\") |
| “; toReturn += “ ![](\"bar_left_down_top_torpg.gif\")   |
“; } else { Yes, you really are looking at HTML completely hard-coded in C++. Look at all of those lovely escaped characters! Notice the complete lack of any separation of content and style. I call this method of website generation the anti-stylesheet. And the purpose of “if (torpg) {“, of course, is to make the site look one way for one specific section and then a different way for the rest of the site. It’s a completely hard-coded approach to site templates. Want to change the look of the site? Just add another else if, modify the hard-coded HTML appropriately, re-compile the program, adjust your input files to trigger the new template, re-compile the site, and presto! It’s that easy. The site also didn’t have any semblance of a directory structure, so the makeSite program, all of the data files, and all of the generated HTML all resided in the www root directory. I also didn’t have any security, so simply by looking at the source code you can piece together the name of every data file and then load it in your browser by choosing the appropriate URL. The href=”http://www.cydeweys.com/archive/makeSite3.cpp”>entire source code to this program is even available in the same way; take a look if these code snippets intrigued you, but you just want to see how this colossal mess all fits together. Notice how the program is also one main function and one subroutine. Hell, at least I used a subroutine, right? And there isn’t a single comment, of course. This was back before I thought I was too good to need them. And despite all of its shortcomings, I’m still damned proud of this program. It was inefficient and ugly as hell, but it worked, and I was proudly able to say that I had written my own website, not just in a mark-up language, but in a true, honest-to-God programming language. I don’t think I’ve ever seen another website that was written in C++, let alone statically generated. I value that uniqueness. Whereas other people dismissed the idea of writing a site in C++ out-of-hand, I was that fool who stood up and said, “I’ll do it!” I’m proud to display my terrible programming choices for all the world to see, and prouder to say that I have learned from them. So, me, ashamed of my code?! Never! 3 Responses to “Don’t ever be ashamed of your code”Feel free to leave a comment:
Powered by
WordPress
|
June 14th, 2008 at 01:12
Actually, Bloglines is written in C++ and is blazingly fast. Although somehow I think it looks different from your code…
Static-generated websites were all the rage about ten years ago. IIRC this was one of the big selling points of Dreamweaver or some such package at the time.
June 14th, 2008 at 09:27
Yes, but Dreamweaver actually had a GUI and such. It’s a little bit different.
I probably would’ve made my program dynamic if I had known how.
June 15th, 2008 at 12:27
The great thing about Dreamweaver is it assumes no one’s going to ever look at the underlying HTML, so it ends up creating the most ugly, unreadable, table-based crap ever. Well, maybe not ever; FrontPage may have it beat, but Dreamweaver’s still pretty bad. :P
Hand-coding websites > *