Naming

An important aspect of creating maintainable code is its readability. Part of readability is the naming of artifacts such as files, type names and methods. Code should be written in a way that makes it obvious what it is doing from the naming. That way anyone visiting the code can understand what it is trying to achieve at a glance.

Abbreviations

Unless it is a well understood abbreviation, such as XML, JSON or something that is well understood in the domain you’re targeting, abbreviations should not be used.

Pluralization

Features in a system are often a representation of a noun in the domain you’re working on. You should look at it as a grouping and therefore pluralize the name.

For instance, let’s say you have a concept called Employee. The feature working on it would then be Employees.

This applies to database schemas, folders for containing the feature, API routes and in general groupings.

Examples

Folder structure

<Project>
├─── Read
│    └─── Employees
│         └─── Employee.cs
|         └─── Queries.cs
├─── Web
│    └─── Employees
│         └─── Employee.tsx

API route

/api/Employees/{employeeId}/details

/api/Employees/8e6bf5b7-9fbb-4ce8-969c-d8d96b9e40dc/details

Prefix / postfix

Adding a prefix or postfix to type names should only be added if it adds value and increases the general understanding. Instead of adding post/pre-fixes; make the naming unambiguous and reflect what it is doing, not what technical shape and/or pattern it is adhering to as that can change over time.

Below are examples that should be avoided.

• Controller
• ViewModel
• Exception
• Factory
• Manager

Adding Base to a base type is another example of pre/post-fix that in general does not say what it is doing and should be avoided.