3

If an enum type is dedicate only to a specific class, does it make sense to declare it inside the class itself? I mean, would it help to understand that this enum type was designed to be used only with this class? Another option would be to put them inside the same namespace.

We also need to consider that another Dimension class could need a different enum type always called toleranceType.

Thanks.

public class Dimension
{
    public enum toleranceType
    {
        None,
        Symmetric,
        Deviation
    }

    public toleranceType ToleranceMode { get; set;}
}

Instead of:

public enum toleranceType
{
   None,
   Symmetric,
   Deviation
}

public class Dimension
{
    public toleranceType ToleranceMode { get; set;}
}
  • 6
    I'd always go for option 2: do not nest them. But all answers to this question (including mine) will be purely opinion-based. So having stated my opinion, I've also voted to close this question. – David Arno Sep 7 '17 at 10:51
  • Disagree that this can only be answered with opinions. If a project needed this nested definitions refactored in our out because of (costly) reasons, that would be experience-based. – Tim Grant Sep 7 '17 at 11:03
  • @David: what if you have 100's of enum types and some of them need exactly the same name? – abenci Sep 7 '17 at 12:08
  • Then you have a serious design problem, both with having 100's of them in the first place and worse, much worse, having any that share the same name. The latter is likely easily fixed, eg by renaming toleranceType in your example to dimensionToleranceType. – David Arno Sep 7 '17 at 12:19
  • 1
    @David: In the end what you are suggesting is very similar to declaring Dimension.toleranceType enum. Please consider that some projects can be really big. – abenci Sep 7 '17 at 12:51
2

I don't think there is any compiled code difference between a nested enum and one in a namespace. You are just appending the container class or namespace to the full name.

However, Its usual to put classes in thier own files for readability.

Given that you don't get any functional difference, I would go with the convention of a new file for the enum, and just give it an appropriate namespace

If you have a pattern of many small classes each with its own specific enum, then I can see that nesting might be a neat solution though.

0

I would not nest the enum values as they are public. This is the recommendation from Microsoft on .Net design guidelines: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/nested-types Namespaces are how you avoid naming collisions, not via nesting.

I'd also make the enum's name PascalCased.

  • Thanks for the link, I am now wondering: suppose you have a Cube and a Pyramid classes and both need faceType enum with different options. Keeping them outside the class definition means naming them as cubeFactType and pyramidFaceType that is so close to Cube.faceType and Pyramid.faceType. Don't you think? – abenci Sep 8 '17 at 12:48
  • @abenci No; one is nested, the other is not. Nesting can have bazaar side effects; the actual name of the type in .Net becomes Cube+faceType. In C# you use the dot, but in the IL its a plus, which can show up if you ever need to reference the enum type in a config file, for example. The other issue is you're doing something most developers don't expect; the framework follows the published guidelines, as do more component vendors. You can ignore them, but it becomes jarring to read code which follows a different set of standards. – Andy Sep 8 '17 at 17:23
-1

Enums are often a sign that you aren't properly designing your objects and each enum value is better off being an object with a common interface, especially when a lot of your code is in if and switch statements based on values of an enum. Enums are more of a procedural coding concept and their use should be limited in truly object oriented code. Personally I find them most useful to make related constants more obvious and be more readable, especially when they aren't driving functionality themselves. This question has more about appropriate uses for enums in an object oriented design.

To answer your question more directly, keeping enums outside class definitions is usually the better choice, but only in situations where an enum is a good choice to begin with.

  • 1
    you are going to have a lot of classes if you have an object with more than one enum property – Ewan Sep 7 '17 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.