Cover image for post iRefuseToUse aNamingScheme

iRefuseToUse aNamingScheme

I find the recent discussion about good naming schemes quite funny. Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. As Lars pointed out:

as short as possible, as verbose as needed

and

you must understand the name without studying specific rules before

I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

Good examples are Persistable which indicates that an object implementing this interface can be persisted, Configurable or Connectable. Abstract classes usually model a common base for other classes and define how these are being used Reflector and Configurator are good examples for such semantics. If this does not indicate their abstractness good enough to you, you can still indicate that this is a basis for other classes to be extended before being used: BaseReflector or BaseConfigurator.

In fact for me, the abstractness of a class does not really matter that much. Most commonly you also provide descendants of this class and it is commonly clear that one should not use DatabaseHandler but either of OracleHandler or MysqlHandler.

Just my .02.