Naming Convention Definition:

A set of standards that create a well-organized object model as well as an easily understandable assembly file folder structure.

Naming Convention Justification:

The Primary Technical Imperative in Software Development, as defined by Steve McConnell in Code Complete 2, is to “Manage Software Complexity”.  Enterprise applications are inherently complex.

Proper usage of .NET namespace and matching Assembly folder structures will have these advantages:

1. Map Business Entities to Development Assembly Structure

2. Organize Assemblies into related Software Entities

3. Create a .NET Entity Object Model that groups related Functionality

4. Prevents Naming Conflicts with Common Dependency Entities

5. Facilitates Multiple IDE Solutions that consume Common Dependent Assemblies

6. Prevents Class File Explosion within a Single Assembly Root Folder

7. Organizes Like Files into Folders that map directly to the Assembly namespace

8. Reduces the Cost of Development and Learning Curve for Change Requests

9. Facilitates Logical Refactoring based on Related Functionality

It is the professional responsibility of all Enterprise Developers to be cognizant of this primary imperative.

Naming Conventions:

Namespaces should follow the [DomainEntityName].[AssemblyName].[Purpose].[RelatedPurpose] format where the DomainEntityName is the root business functionality name and the AssemblyName is the functionally that is support the Business requirement. The functional purpose of a Type using the Namespace can be in a hierarchical structure.

The naming convention for the assembly will define the root namespace. The folder structure of an assembly will always define the appended namespace. Every software entity’s namespace will be name the same as the folder in which the file resides. This will help prevent naming conflicts with like named entities.

All Namespaces will use Pascal casing and separated by a period. Exceptions to Pascal casing can be made based on legacy and business requirements. This will be on a case by case basis and not adhoc. Acronyms can be used as caps when they bring better business understanding.

Pluralization can be used when it adds a better understanding to the intent of the Namespace.

Never name a Type the same as a Namespace. This creates an Assembly and Class ambiguity for fully qualified names.

Do not use generic names, keywords or other common names to Namespaces and Assemblies as this could create ambiguities as well