On Second Thought: Naming Conventions

About five years ago, I wrote a rant about naming conventions inspired by my pet peeve of the redundancy between package names and the names of their contained classes. Essentially, I didn't like seeing things like recipe.RecipeList and proposed that recipe.List was a better choice.

The problem with this convention rears its ugly head in Java. If you need to reference two or more different classes with the same names in a block of Java, you have to fully qualify all but one of them. For example, you might be declaring variables like com.spumco.recipe.List recipeList = new com.spumco.recipe.List(). That's a tad verbose.

Dot Net made this a little more elegant, only requiring you to provide as much prefix as necessary for the compiler to differentiate the classes. For example, if you had com.spumco.recipe.List and com.cyberdyne.exercise.List you only need to reference them as recipe.List and exercise.List.

Therefore, on second thought, I have changed my spots when working in an environment that doesn't make it easy or elegant to differentiate between same-named classes, such as Java.