I always seem to come back to this question and cannot settle on a convention that I'm comfortable with or that I can concretely define: when naming a constant, how narrowly or broadly should it be named?For instance, let's say I've written a workflow application that has workflow items (instances of the workflow) and those have, among other properties, a stage name.  When a workflow item is being initiated, it will get the initial stage name, which should be a constant.  Should I name the constant, e.g., InitialStageName or should I name it LoanApplicationApproverStageName (assuming the first stage is the loan application approver stage).  In both cases, the value might be something like LoanAppApprvr.I guess it boils down to this: is it more important to name the constant based on how it's used (e.g. as the initial stage name) or on what it means (e.g. the stage where the loan approver performs their work)?  Or should there be some marriage between the two -- possibly by having two separate constants that share the same value?
How narrow or broad should constant names be?
design;naming
The place where your constants are defined is also important as that information enhances the constant, without making the name longer.Compare a class Constants that holds all the constants and is in the namespace MyApp.Global. You can have constants in there called Width, Height and Radius that really don't mean a lot being in there. These constants benefit from having clearer names, such as DefaultSquareWidth, DefaultRectangleHeight and DefaultCircleRadius.Compare this to a constant defined in the MyApp.Shapes namespace on the Circle object. The meaning of a constant named DefaultRadius would be very obvious because of where you can find it.Ask yourself the question if typing the constant name in a certain place will make it immediately obvious what it means. Typing MyApp.Global.Constants.Radius is a lot less obvious than MyApp.Shapes.Circle.DefaultRadius or MyApp.Global.Constants.DefaultCircleShapeRadius.