Order of subject and modifiers in variable names

coding-stylenamingvariables

I'm looking for experiences regarding the ordering of the subject and modifiers in variable names.

A simple object Shape would have just a subject for the variable name, such as Area.

A slightly more complex case Sphere which has a wall will have an inner volume and an outer volume, which is where my question comes into play.

What's preferred between Modifier-Subject or Subject-Modifier?

As an example set:

class Containers_Modifier_Subject
{
  AreaAdjustmentFactor
  WallThickness
  Height
  Length
  Width
  AdjustedArea
  SurfaceAreaInner
  SurfaceAreaOuter
  LongWallArea
  ShortWallArea
  TopArea
  InnerVolume
  OuterVolume
}

class Containers_Subject_Modifier
{
  AreaAdjustmentFactor
  WallThickness
  Height
  Length
  Width
  AreaAdjusted
  AreaInnerSurface
  AreaOuterSurface
  AreaLongWall
  AreaShortWall
  AreaTop
  VolumeInner
  VolumeOuter
}

The trigger for my question comes from an object that is similar to the examples. There were enough variables in the object that only a portion displays in the code ahead / lookup window from the IDE. I want to make sure that any future developer is quickly led to the correct variable that they'll be looking for without having to scroll up and down through the lookup window.

In my case, I was looking for the total area, but the area factor and adjusted area values had popped up first.

Consistency in naming as a code standard is a given.

Which naming approach has been:

  • most maintainable?
  • more easily understood?
  • semantically correct?
    • i.e. how well does the variable name match the business object and how well does the variable name flow into conversations about the problem being solved?
  • conducive to being used with code lookup functionality like Intellisense or the various Eclipse based constructs?

Best Answer

You're thinking along the right lines. Most people prefer names they can read in their head and have it sound close to regular English.

However, the fact that you are having difficulty with long lists in intellisense isn't a variable naming problem, it's a class size problem. When you start needing to differentiate by a prefix, that's a good sign you need to split that prefix off into its own entity somehow. For example, Container.Area[INNER]. Use the features of the language, that's what they're there for.

Related Topic