Proper naming of enum values for C#

How do you think, is it a good idea to have such an enum:

enum AvailableSpace {
   Percent10,
   Percent20,
   SqF500,
   SqF600
}

The question is about the semantics of the values names, i.e. both percentage and square feet. I really believe that it's not a good idea, but I could not find and guidelines, etc. in support of this.

EDIT: This will be used to determine a state of an entity - i.e. as a read only property to describe a state of an object. If we know the total space (i.e. the object itself knows it), we have the option to convert internally, so we either have only percentage, or square feet, or both. The argument is, that "both" is not a good idea.

The above is an example of course, but the real problem is that some data providers send us totals (sq.f.), and others percentage, and my goal is to unify the UI. I'm free to make some approximations, so the exact values will be adapted based on how accurate we want to present the information.

The question is only about the semantics of the value names, not the content - i.e. if it is a good idea to put percentage in an (potential) int enum.

From stackoverflow Sunny

• If at all possible, I'd rather break your example into two values, where your enum is "Percent" and "SquareFeet" and the second value is the quantifier. Tie these together in a struct.

  If the context allows for it, it may be even better to create two wrapper types "Percent" and "SquareFeet" and then create some operator overloads, so you can do things like "new SquareFeet(500) + new Percent(20);" and eliminate the use of enums.

  Update: Your naming scheme would be appropriate if the values were industry recognized terms, almost to the point of being symbols. For example, it's safe to have an enum that contains values such as "ISO9001" rather than two values (an enum containing "ISO" and an int of 9001). It'd also be appropriate to have an enum like below:

  public enum OperatingSystem
  {
      Windows95,
      Windows98,
      Windows2000,
      WindowsXP,
      WindowsVista,
      MacOSClassic,
      MacOSXTiger,
      MacOSXLeopard
  }
  

  If the terms "Percentage10" and "Sqf500" are not terms of art or well defined in a spec, data dictionary, etc. then it's inappropriate to use them as values in an enum.

  Sunny : I clarified the question, please review.
  From C. Lawrence Wenham

• The answer: No, it is not a good idea to use enums for representing values. Especially values in two semantically distinct scales. You should not use enums for values.

  The reason: What's the relation between the enum values from the two scales, like Percent10 and SqF600? How do you expand the list of values you can represent within your code? How do you do comparison and arithmetic operations on these values?

  The suggestion (not asked for, but nevertheless here it is. :-)): The semantic of what you are trying to do would be better reflected by a struct that contains two fields - one for absolute area and one for percentage available of that absolute area. With such structure you can represent anything you can represent with the enums above. For example, data providers that give you absolute area, are represented with a struct with the area and 100% available. Data providers that give you percentage, are represented with a struct with the percentage they set and the absolute area such that the percentage of that area is the actual available area the data provider wants to report. You get "normalized" representation of the data from both type of providers and you can add couple of operators to enable comparison and arithmetic calculations with instances.

  Sunny : I agree, that if I need the values for something else, than pure presentation, I'd go with both (maybe in a struct). But it's just a limited list of states (characteristic) I need to present. I just could not come with better explanation.

  Franci Penov : That does not change the answer. You asked if lumping these in one enum is a good - it's not. :-) You need some sort of "normalized" format. The second part of my suggestion is about what that "normalized" representation could be, but you are free to choose your own. Enum is not it, though.
  From Franci Penov