Rant of the day
After working with code on physics projects for three summers now, I've come to a very simple conclusion: 95% of all physicists can't write good code to save their life. This is undoubtedly because they're just unfamiliar with the rules of good programming, so they tend to be extremely overly cautious in some areas and just plain sloppy in others. Physicist coding seems to follow a few simple rules, enumerated below. (All rants apply to C code. I could rant about the Fortran code too, but I think its mere existence is really all I need to say on that front.)

1) The purpose of -Wall is to produce all those pretty warnings. That gives you an impressive feeling of just how long your program is. (Seriously. I don't think I've ever compiled another person's code with -Wall which didn't produce at least two screenfuls of warnings. This is true even when their own makefile included -Wall.)

2) All functions must be declared "int", but if you don't really need to return anything, then don't bother with those pesky return() statements! Conversely, when calling a function that returns a value, you must always carefully save that value, even if you have absolutely no plans to ever do anything with it.

3) Code should never actually be deleted. If you need to take out a particular piece of code, always comment it out. After all, even if the old code is flagrantly wrong or outdated, you'll never know when you might need it again!

4) Loop variables should be given descriptive names such as "loopvar", thus freeing up the precious single-letter variable names for more important variables. The capital single-letter variables are used for strings, of course.

5) Comments of the form
i += 2; /* adds 2 to i */
are perfectly reasonable. Under no circumstance should a comment attempt to explain why one might want to add 2 to i, however.

6) Function prototypes should be strewn throughout the source file, preferably right in front of the function that needs to use the prototyped functions. Under no circumstances should they be placed in a header. Similarly, one never needs to include the header files for library functions -- the compiler knows what they are, right?

7) A char array that you're planning to use as a string should be as big as the number of characters in the string. (My favorite!)

8) The word "const" does not exist. (This might seem like a petty gripe. It's just that I always cringe when I see declarations like
char *filename = "some hardcoded filename";
and not just because of what's on the right side of that assignment.)

9) It's perfectly okay to name an ordinary variable LIKE_THIS, as long as you don't really plan on changing it. Similarly, a #define'd value you might want to name like_this, in case you want to change the value later.

10) Indentation, placement of braces, and so forth should be done as inconsistently as possible. To ensure the best possible performance in this area, maximize the number of people, each with their own programming style, working on a single source file.

11) Source code management does not exist. As per (10) above, have as many people as possible working on a single file at once. However, should you need to branch the code, make as many copies of the original source code as you need for each situation you might have to deal with and modify each one independently.

I'm sure I'll think of more items to add to this list as time goes on.