"If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor."

This may be the single most important piece of advice in the history of writing source code.

Then why do I keep running into violations of this. Just yesterday. Again today. 3 times last week. It's tough enough sifting through your garbage when I don't know what the variables means, it's 10 times tougher when I can't find them.

The solution? If you ever murder a programmer who wrote

  for x = xx to xxx

the penalty should be an $18 fine and community service.

[Seriously, I would amend this rule to, "No variable name should fully contain any other variable name or reserved word." If I do a global search for "vendEmail" I should get every instance of that variable and nothing else. Naming variables is not rocket science. Sometimes it just seems that way.]

Your variable "vendEmail" contains the keyword "end" and is forbidden according to your rules (depending on your language of choice, of course).

Do what I say, not what I do. (Guilty as charged, bad example.)

So when naming a variable, I have to remember all other identifiers in the project? Seems impractical, especially for large projects.

My guideline is to use descriptive English words, not abbreviated. I take a minute to find the right word, check the dictionary or Google when necessary. If the same identifiers are used across the codebase, then they're used to describe similar feature. A little extra typing saves lots of debugging time. Not that my code has any bugs, mind you :)

The other guideline is to spend more time choosing names for interfaces than for implementation variables, but that's just part of the general "interfaces are more important to get right."

>>The solution? If you ever murder a programmer who wrote

>> for x = xx to xxx

>>the penalty should be an $18 fine and community service.

I would respectfully submit that the community service has already been done (by definition), and that $18 is sufficient to cover the cost of the paperwork.

Thankfully this is not a problem at all with Vim. No doubt Emacs can easily avoid the problem as well.

Does your editor of choice not support rudimental word boundary search (\b in regexp terms) ?

Using i and j as loop or temp variable names when working with complex numbers should get bonus points ;)

Ancient, but awesome

Could I make a request for an example of good documentation? Obviously this is hilarious, and for the most part "do the opposite" would work just fine; but a readable, friendly, best-practice "this is how you should document stuff" article would be appreciated.

I always tell my Indians: Write all comments and code with an eye to them getting read in two years by a man you've never met who does not speak your language, has never heard of this project before, and needs to fix the bug that brought down the server in less than 2 hours or the boss will have his hindquarters. Because that is EXACTLY who will be reading this next.

Compliance with this direction is... sporadic.

/ implement first business logic */ public void process() { ... }

Do the needful and reply to me the same.

the variation on that is "a psychopath with a chainsaw will maintain this code. he knows where you live."

then you do pop quiz-style code reviews. let someone's code get reviewed by his peers.

If you were to send in your code to someone as sample code for a job interview would you need to change anything?

My first "real" job was basically maintenance programming. This is priceless indeed =)

I printed out sheets with the following quote in big block letters and passed them out to my fellow programmers:

"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live"

Substitute code with prose, finagle a bit and this is great writing advice.

This document is so extensive it's eerie.

How To Write Unmaintainable Code? Write maintainable code in Perl.

I think we can write Unmaintainable Code in all programming languages.

Hahaha this is fu..ing hilarious

unused local variable warnings? i = i; PRICELESS

This is old stuff, but it cracks me up every time I (re)read it. My favorite one is:

#define TRUE 0

#define FALSE 1