Naming is the Design

There are only two hard things in Computer Science: cache invalidation and naming things.

- Phil Karlton

Yes, naming is hard but it is also very important. We tend to think that big complex architecture is the software design and that type and member naming along the way is just something that is hard and that we screw up. My point here is that naming is the software design and that on a daily basis to me, it is more important than architecture.

If naming is good:

• It will be easier to understand the code and get the big picture
• API will be simpler to user and there will be less bugs
• There will be a greater chance that code for some new feature goes to the right place and that software will evolve gracefully instead of becoming a big ball of mud

In book Domain Driven Design, Eric Evans describes the term Ubiquitous language for the practice of building up a common, rigorous language between developer and users, and we can think of this as naming on steroids. Also Obfuscation can demonstrate the importance of naming because obfuscated code has worst possible names so that is almost not human readable.

Naming and Cohesion

As applied to object-oriented programming, if the methods that serve the given class tend to be similar in many aspects, then the class is said to have high cohesion. In a highly cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable. - Cohesion

IMO types that have high cohesion are easy to name. Low cohesion types are hard for naming because usually they are schizophrenic and do many (unrelated things). So we can think of a good name as a necessity that will force good design decisions. 

Code Example

I want to give an example of bad naming that irritated me enough to write this post. Here are some JavaScript DOM Event methods.

• cancelable - Returns whether or not an event can have its default action prevented
• preventDefault() - To cancel the event if it is cancelable, meaning that any default action normally taken by the implementation as a result of the event will not occur
• defaultPrevented - Returns a boolean indicating whether or not event.preventDefault() was called on the event.
• bubbles - Returns whether or not an event is a bubbling event
• stopPropagation() - To prevent further propagation of an event during event flow
• cancelBubble - Indicates if event bubbling for this event has been canceled or not.

For me, it is hard to remember names of function and properties because they are not consistent. Here are some terms that are used interchangeable in API but mean the same thing:

• stop, cancel, prevent
• bubble, propagation
• cancelable, hasDefault

Below is my proposal for renaming this API that should be trivial to remember.

CodeProject