Tuesday, December 20, 2005

Software Practices That Piss Me Off Too

R's post about software practices that piss him off was such a good idea that I feel obligated to do the same now. Thinking up original content is HARD:) Maybe if some of the other posters to this blog pulled their weight (*cough* Paul *cough*). But I digress (which is only slightly better than egressing I guess).

My top five peeves are as follows:

5) Repeating the same code over and over and over and over and over and over again throughout your code base: Pst...hey dumb ass...they solved this problem way back in the 1950s. Its called a function. Learn about them. They are your friend.

4) Curly braces: There is one and one way to use them:

//Note: This always evaluates to true, unless the Eric has managed to
//drop some sort of foul smelling sauce on her...
if (Sue.IsASexyBitch)
{
Eric.MakeWithTheLoving();
}

Any other way is wrong. Its so wrong that we had to put this in our coding standard because SOME people can't just see that it is wrong and need the Nazi-like brutality of the "PROCESS" to stop them (can you tell I have no found feelings for the "PROCESS"?).

3) Writing functions that are more than 80 lines long: I swear to you this is true. I've now seen at least three production systems fielded to the US Army that contain single functions that are FIVE PAGES LONG. Have you ever tried to wrap your brain around five pages of text at once? Try it some time. Its not a pretty picture.

2) Using Object Oriented structures like a f#$king C programmer: I've lost count of the number of times I have seen people who grew up with functional programming try to turn everything else they see into one giant function graph. This is right:

Objects = data + operations + useful abstractions

This is not:

Objects = place to put functions

If you are in camp number two, please don't work anywhere I do.

I know you are all waiting with baited breath here for #1!

1) Using code you don't understand: OMFG I hate when I see this comment in code:

//I don't know why (perhaps because I am too much a n00b
// to understand compilers, or I have a EE degree but I think
// I should be writing code), but without the next line the
// code afterwards does not work.
<Some code that makes no sense>

And believe me, I have seen this way more than I would like. In live systems. That affect safety of flight. Remember that the next time the you get on a plane.

COM was probably the worse. I swear approximately four people on earth (I was one) actually took the time to understand the problem COM was trying to solve and why it was implemented the way it was. Everyone else just blindly starting using it without any idea what the heck was going on. I've seen more butchered ATL code and code that does unbelievely bad things in COM than any other tech put together. Just the other day I saw something like the following:

p->QueryInterface(&q);
q->Release();
q->DoSomeOtherWork();

Even if you know NOTHING about programming, that sort of code should look wrong to you. Very wrong. Like crashing when you have just 10kb left to download of a video of Anna Kournikova and Tina Fey kissing naked wrong. Worse is there was even a comment explaining why this clearly wrong thing to do was the right thing to do! "Because I tested it". F#$king n00bs...

1 comment:

R said...

Hahahahaha, hey Eric, guess what? I never use cout. Bwahahahahaha. printf() FTW!!!