ASP.NET Naming Conventions - how to avoid calling everything a service

Posted on Tuesday, 12 Aug 2014

Naming things can be tricky. I've found that when I'm creating a new class the first class name that pops into my head is usually one that doesn't describe the function and purpose of the class I'm creating adequately enough. It usually takes a few moments of stopping and thinking to myself "What can I call this class that will describe its role clearly to other developers and/or consumers of this API, class or interface - something succinct and no longer than 4 words long" (4 words or less is a general rule of thumb I've picked up throughout my years programming that seems to hit the sweet spot).

Over time I would start to notice patterns occurring. For instance when developing web based applications following a typical n-tier application structure I've noticed it becomes very easy to label everything at the service/business logic level a 'service'. With this in mind I started to do a little googling for naming ideas and found this little gem of a question on every developer's favourite site that highlights a whole range of different naming ideas and conventions that might help describe that class you're creating perfectly.

These are:

  • Coordinator
  • Builder
  • Writer
  • Reader
  • Handler
  • Container
  • Protocol
  • Target
  • Converter
  • Controller
  • View
  • Factory
  • Entity
  • Bucket
  • Attribute
  • Type
  • Helper
  • Collection
  • Info
  • Provider
  • Processor
  • Element
  • Manager
  • Node
  • Option
  • Factory
  • Context
  • Designer
  • Editor
Back