Code Naming Conventions from Ben

* Forwarded from Carolyn

* Today I’d like to get the discussion moving on Code Naming Conventions. I think they are important, just like the database naming conventions, and that a little care results in reduced work in creating and maintaining code. As I said yesterday, I’m not as interested in conventions such as what case you use, as long as you pick something and remain consistent. I’ll just add some thoughts here to get your ideas flowing.

These are pretty much personal preferences I have picked up from things I liked that others have done. I don't have a lot of thought put into them, and for some of them, I don't even have compelling reasons. But it should give you food for thought.

Most systems are data centric. As a result, I tend to have a lot of classes that are nouns representing some object or entity. I tend to put this in one or more projects based on the subject area they implement. I only use multiple projects if there are a lot of classes that are used only in a subset of systems. I like to use names that fully describe the noun, if at all possible.

I’m big on using interfaces because of the ease of extensibility they bring to code. So, I’ll have another project with the interfaces named the same as the class they support with the prefix I. No big surprise there. If I use an abstract class instead of an interface, I am likely to name that abstract class the same as the base noun followed with a suffix Base to let me know it is a class used as an interface with implementation included.

If my class is not anemic (a future topic) I will have a separate project and unit test established to test any methods or necessary properties of that class. To keep things simple, I like to name my test class the same thing as the class it tests with a suffix _Test. The reason I separate them into a different project is so that I can easily exclude them from a production build.

ORM types of classes also follow similar naming conventions with suffix for the layer in which they reside (say if you are following a repository pattern). Using tools such as Entity Framework, this can be handled for you pretty easily. For those of us who work in other languages or roll our own data access, the principles for naming projects and classes is pretty well known. If you are not comfortable with the concept, follow up on the Respository pattern. === Today I intend to finish up this topic of naming conventions with some further thoughts I have on code naming. Yesterday I presented some concepts with Data Domain Code. Today I want to turn to naming conventions for business logic and application control. One of the things I have picked up as I continue my long, ongoing study of software development patterns is the value of naming classes according to the pattern they implement. For example, if I am using a factory to instantiate a class I am likely to name that factory class based on the kind of object it instantiates followed by the suffix “Factory”. The same technique may be used for a Controller, View, adapter, etc. If I have a number of classes implementing a strategy pattern I like to have a base class name at the beginning of each strategy implementation followed by a description of what makes that particular instance different. This causes all the classes to be grouped together alphabetically in the source code making them easier to identify as working as a group. The description at the end of the class provides more information about how each one differs without having to open the code for inspection.