Superstition has no place in programming

Working on my Big Dirty PHP Project at work, I've found this bit of code in many places.

$categories = "";
$categories = Array();

Why is $categories set to an empty string, and then an array? It's not necessary to pre-initialize a variable before setting it to another value. So why is the code there? It's not just one case. It's throughout the codebase, where I delete the first line whenever I find it.

The original programmer is (thankfully) no longer around to ask, but I'm guessing it's superstition. Perhaps he had some problem that went away for an unrelated reason when he added the first line of the code. The problem is that he never considered why.

Here's another coding horror to avoid in Perl. Ever seen a regular expression by someone who wasn't entirely familiar with regexes and quoted everything whether it needed it or not?

if ( $name =~ /Marcus Holland\-Moritz/ )

The hyphen in Marcus's name isn't a metacharacter, but the unsure, superstitious programmer will quote it anyway. "Eh, it doesn't hurt anything," he may reply, but it also demonstrates his non-mastery of regexes.

If you ever find a piece of your code where you can't understand exactly why it works, why every single statement exists, stop and rework it until you do.



Paul Teetor said:

Thanks, Andy. I agree with you 100%.

At work, I maintain a large body of code written by a non-programmer. Many of his programs (not modules) end with these three lines:



as if he was struggling to finally, absolutely end the program. (And, no, we never use the DATA handle, so we don't need __END__.) I always wonder what other Perl semantics were over his head.... which makes me read the code quite carefully.

Needless to say, I rip out this stuff whenever I see it!

notbenh said:

Thanks for the post Andy, this strikes me as, to some extent, a reference to the previous 80/20% programmer post ( 80% programmers ). When a 20%-er looks the work of an 80%-er, theres a large disparity in knowledge and a completely different goal to there coding. A 80%-er is looking for things to just work, no joy in finding the most elegant solution, not a lot of concerned with efficiency, success is working code. A 21%-er though, will revel in the details. A 20%-er might get giddy when we see the Schwartzian transform, where an 80%-er just sees a mess of code and is confused. It's not bad, just different.

Andy, to answer your point in the post about the need to squash superstition, I completely agree. But I don't think that the way to go about this is to expect some one to refactor there way to enlightenment. When you don't know what you don't know it's near impossible to figure out where your going. The way that I see this getting solved is getting right back to my reply to the 80/20 post, involvement. There is too much bad code that was written in complete isolation. Education comes from a different point of view, diversity, and the clash of ideas. I guess to me the squash of superstition is a code review, make some one else force me to think differently. It's a big portion of how the 20% got to be the 20%.

As a completely separate point, this talk of bad code makes me want to set up a bad code blog, something of the inverse of beautiful code. A place where some one can anonymously post a code snippet, grip about how it sucks and how they would do it differently. I would be most interested in how even with in the 20%-ers how much bickering would happen on the 'best' way to do anything, but thats a completely different topic.

Andy Lester said:

There's The Daily WTF, but it's always been aimed at mockery, not helping. :-(

Leave a comment

About this Entry

This page contains a single entry by Andy Lester published on January 4, 2008 10:13 AM.

Why I love say was the previous entry in this blog.

How to: Create database columns that contain only digits is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Other Perl Sites

Other Swell Blogs

  • geek2geek: An ongoing analysis of how geeks communicate, how we fail and how to fix it.