Naming design programming that something

When I started designing the system, I'd spent a lot of time to design named because good name and good design are inseparable.

The Beginning The WAS the In  Word , and Word The WAS with God, and WAS God The Word
Word was. Word was with God, and the Word was God. (John Chapter I, Section I)

In the design process to classes, methods and functions good name will bring good design, although this is not necessarily true, but if the bad name that will not bring good design to you. During the design process, and if you find it difficult to name a module, when a method may question you are really experiencing is not difficult to name the problem, but this design is really reasonable, you should probably spend more time to redesign the look of your module.

Good name will not only bring good design, good name but also improve the readability of the program, reduce the cost of code maintenance. On the other hand, if the code would bring a bad name invisible wall, so you have to go deep into the code into the code of conduct have to increase your understanding of the code time.

To this end I summarize a few guidelines on naming, hope that a few principles to bring help to design your name, I'm using C ++ syntax, of course, these principles can be easily extended to other languages ​​go.

Named types (classes, interfaces, and structures)

 

Name should maximize the use of the term
Bad:           Happy
Good:          Happiness

 

Do not use a similar namespace prefix
Bad:           SystemOnlineMessage
Good:          System::Online:Message


Do not use too many adjectives can describe clearly on the line
Bad:           IAbstractFactoryPatternBase
Good:          IFactory


Do not use the type Manager or the Helper or the other meaningless words
if you must add or Helper Manager on a type, then the type is named either very bad or very bad design is, if it is after then, this type of management should help manage and help yourself up.
Bad:           ConnectionManager
               XmlHelper
Good:          Connection
               XmlDocument, XmlNode, etc.


If a class can not be described simply naming It has the features can be considered a way of analogy named
Bad:           IncomingMessageQueue
               CharacterArray
               SpatialOrganizer
Good:          Mailbox
               String
               Map


If you use the analogy, you should use them the same
Bad:           Mailbox,DestinationID
Good:          Mailbox,Address


Functions (methods and procedures)

 

concise
Bad:           list.GetNumberOfItems()
Good:          list.Count()


Do not be too simple
Bad:           list.Verify()
Good:          list.ContainsNull()


Avoid abbreviations
Bad:           list.Srt()
Good:          list.Sort()


For functions accomplish something of verbs
Bad:           obj.RefCount();
Good:          list.Clear();
               list.Sort();
               obj.AddReference();


For the return of Boolean functions using similar questioning
Bad:           list.Empty();
Good:          list.IsEmpty();
               list.Contains(item);


For just return property, without changing the function of the state is a noun
Bad:           list.GetCount();
Good:          list.Count();


Do not repeat the name of the parameter in the function names
Bad:           list.AddItem(item);
               handler.ReceiveMessage(msg);
Good:          list.Add(item);
               handler.Receive(msg);


Do not name the name of the method in the class repeat this method
Bad:           list.AddToList(item);
Good:          list.Add(item);


Do not include the return type of the function's name, unless the name of the function must be performed in order to distinguish the type of return
Bad:           list.GetCountInt();
Good:          list.GetCount();
               message.GetIntValue();
               message.GetFloatValue();


And do not use the name or the Or
if you do use a conjunction to connect the function name, the function must be done much better approach is to divide it into smaller functions to process (similar to the object-oriented design single responsibility principle guidelines of).
If you want to make sure that this is an atomic operation, then you should use a name to describe this action or a class to encapsulate his
Bad:           mail.VerifyAddressAndSendStatus();
Good:          mail.VerifyAddress();
               mail.SendStatus();


This is a very good article, I use my language in the organization a bit, if you like the English readers can click here to read the original text