"A foolish consistency is the hobgoblin of little minds."
-- Ralph Waldo Emerson, "Self-Reliance"

I haven't read the essay, so I'm not sure whether in it Emerson tries to explain the difference between foolish and wise consistency. So, at the risk of being labelled a fool, here are some programming consistencies which I'll toss out there as "wise".

• Consistency in code spacing, indentation, and naming. Apart from the benefits your team reaps from having a code base that looks as though it were written by one person, you'll have the satisfaction of creating code like a professional. Who'd want to buy, or even borrow, a book with inconsistent spacing, indentation, capitalization, spelling, typography...? I have my preferences for coding conventions, but if they clash with the consensus of my team, I'll do as the Romans do.
• Consistency in build process. I'm a huge fan of continuous integration. I'm also a huge fan of everyone on the team building the project using the same build scripts the continuous build would; not everyone hopefully getting their IDEs configured the same way and building via the IDE.
• Consistently writing automated behavior specifications for the code, as the code is being developed. Call them "tests" if you must, but I'm really into treating xUnit tests as a design tool, as a crucible in which to fire and shape design ideas. No more of this post-facto, horrendously duplication-riddled test script cranking. Treat your automated "tests" as first-class citizens, creating and maintaining them with as much care as you would the code it's exercising.

What programming consistencies do you find wise? Foolish?