Shorter naming convention for types.

Question

I am developing a framework, and some of the objects have reaaally long names. I don't really like this, but I don't like acronyms either. I am trying to come up with a shorter name for "EventModelSocket", basically a wrapper around the .Net socket class that implements various events, and methods to send files, objects, etc. Some of the objects have really long names due to this, such as "EventModelSocketObjectReceivedEventArgs" for example.

I've tried everything from a thesaurus, to a dictionary to sitting here for hours thinking.

When you come upon situations like this, what is the best way to name something?

Answer 1

Well, are the long names hurting something?

(edit) two other thoughts:

• use var in C# 3.0 - that'll save half the width

• if you are using the type multiple times in a file, consider a type alias if it is annoying you:

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 2

I for one use the long name. With intellisense typing out the name isn't that important, unless you are using a 15 inch monitor.

If I had to reduce the name I might go with EvtMdlSck just make the work shorter but still understood. Even though that is not my preference.

Answer 3

Push some of it into the namespace.

For example:

EventModelSocketObjectReceivedEventArgs

becomes

EventModel.Sockets.ReceivedEventArgs

Answer 4

I would just suggest using the most concise naming that describes the object. If EventModelSocketObjectReceivedEventArgs does that, move on. My 2 cents.

Answer 5

Years ago when I was in a programming class, the prof quoted the statistic that a piece of code is typically read 600 times for each single time it got modified. Nowadays, I would assume that this is no longer true, particulary in TDD environments where there's lots of refactoring going on. Nevertheless, I think a given piece of code is still read many more times than it gets written. Therefore, I think the maxim that we should write for readability is still valid. The full form of a word in a name is more readable, since the brain doesn't have to do the conversion. Comprehension is faster and more accurate.

The tools we have today make this so easy with autocompletion and the like. Because of this, I use full words in variable names now, and I think it's a good way to go.

Answer 6

If you need to go through that much effort to find an alternative name, you already have the correct name. Object/method/property names should be self documenting. If they do not describe their exact purpose they are misnamed. There is nothing wrong with long names if they give the most clear understanding of the purpose of that object.

In this age of intellisense and large monitors there really is no excuse to not be as descriptive as possible in naming.

Answer 7

Some criticisms on your naming...

Why DOES your component have the word "model" in its name - isnt that a bit redundant.

Since your component seems to be a messaging hub of some sort why not include Message in its name. What about MessageSender.

To solve your problem I would create an interface and given it a generic name like MessageSender and an implementation which is where you include the technology within the name like RandomFailingSocketMessageSender.

If one wishes to get a good example of this take a look at the Java or .Net libraries..

from Java. interface - class/implementations... Map - HashMap, LinkedHashMap. List - LinkedList

Details regarding the technology or framework used eg words like "Socket" or perhaps to use a contrived example "MQSeries" shouldnt be part of the interface name at all.

MessageSender seems to IMHO sum up the purpose of your component. It seems strange that your thing which sends "files" and "events" doesnt include the those two descriptive words. The stuff your using in your naming is superfluous and IMHO doesnt match your description of the component.

Answer 8

Don't remove the vowels or something crazy like that.

I'm with the "stick with the long name" people.

One thought is that if the names are that awkward, maybe some deeper rethinking of the system is needed.

Answer 9

In general I believe in classnames that accurately describe their function, and that's it's OK to have long names. If you think the names are really getting long, what I would suggest is finding a concept that is well-known to your programming team and abbreviating that. So if "Event Model Sockets" are a concept that everybody knows about, then abbreviate them to EMS. If you've got a package that is entirely about Event Model Sockets then abbreviate them to EMS in all the classes internal to that package. They key here is to make sure the name is in full for anyone who might not be familiar with the concept and abbreviated for anyone who is.