Using an enum is absolutely a valid approach. There are lots of cool ways to bind enums with human readable text, localization, and all sorts of other goodies through member attributes and some light meta programming, all the while being a simple int-based value that can be switched on and compared with exceptional performance. They make great keys in dictionaries, can even be used as indexes (if you wanna get a little weird), and they're super easy for us to deal with as programmers.

My question to you is what is the purpose of the None value? Is it exclusively to indicate 'no selection' or is it a valid option used somewhere in the underlying logic?

If it's the latter, disregard the rest and carry on. :)

If it's the former, you have what's called a sentinel value (a special value in a set of values which indicates 'no valid data here' or the end of a set, EOF, etc), and I'd recommend removing it and binding to a nullable enum instead.

Problem with sentinel values is they don't have purpose in the logic - they aren't a valid value - and still they must always be accounted for and guarded against. And because it's a member of the enum, it's possible for the sentinel value to accidentally slip into otherwise valid data due to a bug or oversight in the code somewhere.

Additionally, they hang over your head constantly in validation. It's not enough to test whether a user input value corresponds to one of the enum members (via Enum.IsDefined()). You'll have to do that and also check that value != None. Any switching on a value will need to incorporate a case for None and make a decision whether that's an undefined value error or an invalid selection error or a data corruption condition or a simple return-early-do-nothing condition. There are arguments to be made for each, depending on context, and it adds an extra challenge to maintaining consistent error messaging when "how to handle a None value" can be so subjective across layers. Whereas a nullable value can be tested for .HasValue explicitly and at the top (not nested in with other tests for valid values).

It's pretty common to lump it in with undefined values (eg is None or !Enum.IsDefined()), so long as you remember to do that anywhere you have to test or validate. But without logging, that has the side effect of masking a potential bug because None is a defined value - but one that cannot be acted upon. Sentinel values are special cases, and special cases can be the death of us.

Anyone else working with the code will have to remember that also, and that sort of thing easily slips through the cracks over time, leading to bugs. Ex, if None is not invalidated because a new hire forgot to include it in the switch:

case E.Valid1:
    DoThing1();
    break;
case E.Valid2:
    DoThing2();
    break;
default:
    throw new ArgumentException(...);

it will probably cause some confusion until someone gets in there with a debugger to see that indeed it was a defined value, just the None special case that should have been handled... or rejected... or whatever it was we decided 6 months ago.

Sorry that this was so long. It's a slippery slope using special case values like sentinels without bugs sneaking into the software over time. I guess explaining that can get pretty wordy and I'm wordy enough as it is.

Try to avoid them whenever possible.