views:

37

answers:

3

I sometimes see domain objects or enums named with a suffix of "Type", such as 'ItemType' or 'PermissionType'.

The word is so general and non-specific, I wonder if it is being used more often that it should be.

Are class names like these often produced due to a lack of effort to come up with a more meaningful signifier, or is "Type" really the only option in many cases?

+1  A: 

I think the word "Type" is likely at the front of developers' minds, since we deal with types a lot within programming languages. Yes, there are often other options, depending on the situation (e.g. "ItemCategory" instead of "ItemType", "PermissionMode" instead of "PermissionType") but they may not be that much less vague.

If at all possible, I try to use the term that is used by people who work in the domain: i.e. if the folks putting items into packages and mailing them out refer to an item's type, that's the word to use.

JacobM
+1  A: 

When used on a class, it's usually wrong: PermissionType would mean "type for Permissions". It should be just "Permission"

However, I do often see it used on enums --- when the enum is a list of types. i.e. PermissionType does not mean "type for Permissions " but "enum of Permissions types". This would be legitimite.

James Curran
Since "Type" also has the complication of being used in programming vocabulary, when you write "type for Permissions", did you mean 1) "class for Permissions" or 2) "something distinguishable as a variety of Permissions"?
Jon Schoning
"type for Permissions"= (1); "Permissions types" = (2)
James Curran
I understand usage in (1) would be redundant if applied to classes, but what if I want to signify the meaning in (2), is that not applicable to classes? What do I call a class whose purpose is "something distinguishable as a variety of Permissions"?
Jon Schoning
PermissionCollection or PermissionSet.
James Curran
A: 

'Type' is more indicative of the variety and importance of the information.

For example: EmployeeType may refer to pay scale, department, skill level, seniority, etc. or a combination of these factors. You could break these factors out into separate entities with separate names or have combinatorial naming (e.g. SeniorProgrammer) but that may not be worth the noise trade off vs. other more important distinctions.

Thomas Langston