name functional

When naming objects (being it classes, methods or whatever) let the name describe what it is or does, NOT HOW!

An example:
I recently worked on a database where a column was defined by a user defined type. The naming convention used stated that the name should contain the base type used in the udt. In this case it was a tinyint, so the name of the type started with udti_. I had to change the column to a smallint because the original tinyint just couldn't cope with all the different values anymore. Normally one of the biggest advantages of user defined types is that you only have to change the type definition and you're done. In this case I had to create a new udt (just because the name had to change to udsi_) and redefine all tables, stored procedures, functions and triggers that used or referred to the original type.

Describing the inner workings of an object in it's name limits the flexibility in future development and also breaks the encapsulation rules.