Q:

What popular "best practices" are not always best, and why?

"Best practices" are everywhere in our industry.  A Google search on "coding best practices" turns up nearly 1.5 million results.  The idea seems to bring comfort to many; just follow the instructions, and everything will turn out fine.
When I read about a best practice - for example, I just read through several in Clean Code recently - I get nervous.  Does this mean that I should always use this practice?  Are there conditions attached?  Are there situations where it might not be a good practice?  How can I know for sure until I've learned more about the problem?
Several of the practices mentioned in Clean Code did not sit right with me, but I'm honestly not sure if that's because they're potentially bad, or if that's just my personal bias talking.  I do know that many prominent people in the tech industry seem to think that there are no best practices, so at least my nagging doubts place me in good company.
The number of best practices I've read about are simply too numerous to list here or ask individual questions about, so I would like to phrase this as a general question:
Which coding practices that are popularly labeled as "best practices" can be sub-optimal or even harmful under certain circumstances?  What are those circumstances and why do they make the practice a poor one?
I would prefer to hear about specific examples and experiences.

A:

I think you've hit the nail on the head with this statement

I'd hate to take things at face value and not think about them critically

I ignore almost all Best Practices when it doesn't come with explanation on why it exists
Raymond Chen puts it best in this article when he says

Good advice comes with a rationale so
  you can tell when it becomes bad
  advice. If you don't understanding why
  something should be done, then you've
  fallen into the trap of cargo cult
  programming, and you'll keep doing it
  even when it's no longer necessary or
  even becomes deleterious.

A:

Might as well throw this into the ring:

Premature optimization is the root of all evil.

No, it's not.
The complete quote:

"We should forget about small
  efficiencies, say about 97% of the
  time: premature optimization is the
  root of all evil. Yet we should not
  pass up our opportunities in that
  critical 3%."

That means that you take advantage of specific, strategic performance enhancements throughout your design process.  It means that you use data structures and algorithms that are consistent with performance objectives.  It means that you are aware of design considerations that affect performance.  But it also means that you do not frivolously optimize when doing so will give you minor gains at the expense of maintainability.
Applications need to be well-architected, so that they don't fall down at the end when you apply a little load on them, and then you wind up rewriting them. The danger with the abbreviated quote is that, all too often, developers use it as an excuse to not think about performance at all until the end, when it might be too late to do anything about it. It's better to build in good performance from the start, provided you're not focusing on minutiae.
Let's say you're building a real-time application on an embedded system.  You choose Python as the programming language, because "Premature optimization is the root of all evil."  Now I have nothing against Python, but it is an interpreted language.   If processing power is limited, and a certain amount of work needs to get done in real-time or near real-time, and you choose a language that requires more processing power for the work than you have, you are royally screwed, because you now have to start over with a capable language. 

A:

One return per function/method.

