views:

108

answers:

3

Hi all,

Is there a document describing how to name enumerations?

My preference is that an enum is a type. So, for instance, you have an enum

Fruit{Apple,Orange,Banana,Pear, ... }

NetworkConnectionType{LAN,Data_3g,Data_4g, ... }

I am opposed to naming it:

FruitEnum
NetworkConnectionTypeEnum

I understand it is easy to pick off which files are enums, but then you would also have:

NetworkConnectionClass
FruitClass

Also, is there a good document describing the same for constants, where to declare them, etc.?

Walter

+1  A: 

In our codebase; we typically declare enums in the class that they belong to.

So for your Fruit example, We would have a Fruit class, and inside that an Enum called Fruits.

Referencing it in the code looks like this: Fruit.Fruits.Apple, Fruit.Fruits.Pear, etc.

Constants follow along the same line, where they either get defined in the class to which they're relevant (so something like Fruit.ORANGE_BUSHEL_SIZE); or if they apply system-wide (i.e. an equivalent "null value" for ints) in a class named "ConstantManager" (or equivalent; like ConstantManager.NULL_INT). (side note; all our constants are in upper case)

As always, your coding standards probably differ from mine; so YMMV.

Jim B
I want to add that it seems like that object factories are nowadays named using plurals, for example `Lists` and `Maps`. In my opinion this is a good convention and I fully supports its more widespread usage.
Esko
Yeah, they're similar to my personal coding standards, but different to my workplace coding standards. We don't have many standards in place for work, so I'm trying to find a good document to use as a reference.
`Fruit.Fruits.Apple` is too verbose to me, literally breaking the DRY principle :-) I would prefer e.g. `Fruit.Type.APPLE`.
Péter Török
I don't like this approach. The way this is named, an Apple either is-a Fruits, or at the very least it's confusing since it's not clear that Apple is-not-a Fruit. I like Peter's Type example. At least then it's self documenting that APPLE is-a type-of fruit. Though this whole fruits example smells kind of rotten...
Mark Peters
I also don't like this. If 'Fruit' class represents a fruit (and it should) then what can 'Fruits' represent? If Fruit (the class) really is a class for dealing with Fruit then it should be renamed "FruitHandler' or 'FruitManager'.
DJClayworth
+1  A: 

They're still types, so I always use the same naming conventions I use for classes.

I definitely would frown on putting "Class" or "Enum" in a name. If you have both a FruitClass and a FruitEnum then something else is wrong and you need more descriptive names. I'm trying to think about the kind of code that would lead to needing both, and it seems like there should be a Fruit base class with subtypes instead of an enum. (That's just my own speculation though, you may have a different situation than what I'm imagining.)

The best reference that I can find for naming constants comes from the Variables tutorial:

If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.

Bill the Lizard
+5  A: 

Enums are classes and should follow the conventions for classes. Instances of an enum are constants and should follow the conventions for constants. So

enum Fruit {APPLE,ORANGE,BANANA,PEAR};

There is no reason for writing FruitEnum any more than FruitClass. You are just wasting four (or five) characters that add no information.

DJClayworth
I share that same opinion.
I started naming my enums that way, but for readability, I have now been using Fruit.Apple instead of Fruit.APPLE.
@Walter Why would making an enum instance look like it was a class enhance readability?
DJClayworth