The 5 Labours of Naming Conventions

Yeah i know you probably think Hercules has picked up programming as a career.

I’m sorry to disappoint you, he’s still out there adding more labours to his Legend.

While most people don’t have to worry about naming things, its the plight of the developer to come up with names in the course of their work.

This includes one-off things such as name of your latest project to far more frequent such as name of a variable.

The compiler doesn’t care much about our choice of names but other programmers do, the names we give to entities in our project can mean the difference between hundreds of thousands of happy users and a flopped project.

Today we outline 5 things to take into consideration when naming your project.

1. Don’t name it!

Before you escort me of to the asylum, think about this for a second, if all you need is a one-off functionality and that is really short why name it at all?

In such cases it makes sense to use closures to carry off the operation.

2. Use known names

This is a pet peeve of mine. Developers who use cute names deserve a special place in hell. Artistic flair is great but you can bet that the person reading your code will not be a fan.

Common names are everywhere, a good example is using i as an iterator variable.

3. Known conventions

In the absence of a known name, consider using known conventions in the community.

The particulars are best left to your own norms but good candidates include:

Hungarian for Microsoft technologies strUsername
Sentence case for classes, camel case for functions like function iAmAFunction() and class Iclass

4. Affordance

The quality of affordance is where the design is instructive of how it should be used. For example a cup handle has the quality of affordance, you know you should hold the cup just by looking at it.

Names you choose should have the same quality. Examples would be like:

attemptLogin(username,pass) as opposed to say login(data)
saveToDisk(filePath,userDetails) as opposed to say save(path,data)

5. Mnemonic quality

In the quest to be descriptive, we must not forget that the names we write are to be used. To this end we should ensure that the names are easy on the human tongue and therefore consequently easier to remember.

Length of the name should be kept within reason as general rule of thumb

Use shorter names for variable you expect to be used often and longer names for ones you expect less usage of

With this simple rules in mind you can have a better naming scheme and far happier users in no time. For a more comprehensive treatment on naming, make sure to checkout Robert C. Martin book

Clean Code: A Handbook of Agile Software Craftsmanship