24 November 2010

Naming convention
This point covers Naming Convention for C# only. If your native language is some other, you'll have to search on other blogs.. I'm not very familiar with Java, and it's been a while since I worked with PHP, and I hate the C/C++ Naming Convention. Sorry.
This is one of the most controversial points that I'll be covering in the Code Art series. Most of what I'll be suggesting represents my personal opinion, of course I'll try to motivate it. One of the things I hate in Code Convention documents is that the decisions to use one case or another (for ex.) are not motivated by practical use.
So here I go.
When choosing the letters case, the simple rule of thumb would be to use PascalCase for all names except constants, private fields and variables. Constants are usualy typed using all letters upper case and underscore to separate the words: I_AM_CONSTANT. For private fields and variables use lower case camelCase.
In case your private field name should start with some shortcut likce ICBM, make all letters lower case: icbmMissile. Don't do that if you use PascalCase: ICBMMissile.

There are a lot of documents suggesting adding m_ prefix to private fields, for ex: m_variableName. I can't see any reason for doing it. Mistaking a local variable with a private field is kind of hard.. So give up on prefixes to separate the local variables from the "rest of the world", just be a better programmer.
Never add C prefix to classes. This is so last week..
The only prefix that you should use is I for interfaces. There is a recommendation to avoid using I as the first letter of any other class but if you need an I why rename your class to something that does not represent it?

Never add sufixes to variables that describe the type, like managersInt. The original idea was to make it simpler to developer, to not search for the declaration in order to figure out what type is it. But you have the most modern IDE in front of your eyes. Move the cursor other the variable name and you get a balloon with all the information you need (it's a kind of magic).
The most common suffixes are Exception and Delegate. But read forward.

Suggestive names
All the names you give to your classes, interfaces, variables, methods should be as clear as possible and should describe what is it(or what it does).
For example MessageDispatcherManager class - most probably gets message from somewhere and sends it to the right receivers. GetAllMethods method - probably gets all the messages that are waiting on the queue (what it does). allMessagesList private field - here you may argue that I used List as suffix. Yes and no. List is part of the description because this is what it is, a list of something. I can have also a allMessagesCount field - I did not use int as suffix. I described what is it.
It's a common convention to end all exceptions with Exception and delegates with Delegate.
On events it is usual to name them in present or past tense, if the event is fired after an action is performed or before. For ex. Showing - most probably is fired just before a control is rendered (don't take my word that there is such an event). And Showed would like to notify you that the action of showing has just been finished. Also it is usual to name the method that will do the firing of the event with the prefix On: OnShowed, OnShowing.

blog comments powered by Disqus