Member Avatar for Xeros606

I usually make enumerations separate from classes, but when my CS teacher was teaching us about enums, he put it inside the class, and when it came time to set a variable of the enum outside of the class, he told us to just pass a string to the class evaluate that with a method inside the class itself. Is there any reason why one would do this? Is it bad practice to put enums outside of the class in which it is used?

Sorry if it's hard to understand what I'm trying to say. I'll try to make some code snippets to make it easier to understand.

Here we go:

What I usually do:

enum AnEnum {
	Bla,
	Blah
}

public class A {
	AnEnum anEnum;

	public A(AnEnum newAnEnum) {
		anEnum = newAnEnum;
	}
}

What he told us to do (I don't know if that string evaluation is 100% right, but this is pretty much it)

public class A {
	enum AnEnum {
		Bla,
		Blah
	}
	
	AnEnum anEnum;
	
	public A(string newAnEnum) {
		if(newAnEnum == "Bla") anEnum = AnEnum.Bla;
		else anEnum = AnEnum.Blah;
	}
}
Edited by Xeros606 because: n/a
  • 5 Contributors
  • 4 Replies
  • 289 Views
  • 16 Hours Discussion Span
  • Latest Post Latest Post by ddanbe

Dani AI

Generated

Short answer: choose the location based on scope and API design. The nested-enum vs. top-level debate in this thread boils down to two tradeoffs: compile-time clarity versus scoping. The teacher example described by (accepting a string and mapping it inside the class) loses compile-time checking and is fragile to typos and refactoring. Prefer typed enum parameters for public APIs; accept strings only at boundaries (UI, files, network) and validate/parsing there.

A few concrete, often-missed points that build on what and said about visibility and what mentioned about conversions:

  • Explicitly declare accessibility. Top-level types without a modifier default to internal; nested types without a modifier default to private. Avoid surprises by writing public / internal / private explicitly.
  • If the enum models a concept used across many types, put it at namespace level (one file). If it truly belongs only to one class, nest it to keep the API surface small.

When you must accept strings, prefer safe parsing instead of manual string comparisons. Example pattern:

if (Enum.TryParse<AnEnum>(input, true, out var value) && Enum.IsDefined(typeof(AnEnum), value))
{
    // use value
}
else
{
    // handle invalid input
}

Note: Enum.IsDefined is not appropriate for combined [Flags] values.

If enums are persisted or part of a public contract, be deliberate about numeric values and layout. Assign explicit values (and document them) when items may be serialized, stored in a DB, or sent across services. Use [Flags] with powers-of-two values for bitfields, and use singular names for single-value enums (plural or set-oriented names for flags).

Quick checklist: prefer typed enums in signatures, parse strings at boundaries with TryParse, declare access modifiers explicitly, assign explicit values when persistence/versioning matters, and scope the enum where it best expresses intent. This keeps code safer and easier to refactor.

Recommended Answers

All 4 Replies

Member Avatar for darkagn

I prefer your method personally. I go one step further and put enums in their own file with an extension of the TypeConverter class to perform casts between an enum and a string.

Member Avatar for Diamonddrake

There is no reason why you can't, but it depends on the accessibility you need for the enum. If the namespace directly contains the enum than any object in that namespace has access to the enum. When its contained in a class, depending on its access modifier it may or may not be available to all the objects in that namespace.

Typically you would put the enum inside the class if the class encapsulates the extent of the usage of the enum. If the enum has common items to the application that don't explicitly require the use of the class then its up to the developer to make the call.

Member Avatar for sachintha81

My opinion too is your teacher's method is a waste of time, and making things too complex when they can be done simpler.

My usual practice is to put them in a separate file (not a separate class, but inside the same namespace) so they would be accessible from everywhere.

Member Avatar for ddanbe

If your enum only has relevance for a particular class, leave it inside that class.
But most of the time enums have the tendency to be of a more general nature ( my experience ) so I think defining them outside a class is the way to go.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.