EUserAction?

Вы описали это как некое действие пользователя. Однако вы могли бы быть более конкретными. Название позволяет сделать дополнительный выбор в будущем. (Имя должно соответствовать выбору, а не его)

Однако для вашего другого тонкого вопроса:

because they will see this printed in other contexts and I'd like it to be more obvious what the choice was.

на самом деле не должно иметь значения, что видит пользователь. Модель данных может сильно отличаться от той, которую вы представляете пользователю. Достаточно было бы bool. Возможны ли дополнительные действия в будущем?

• Да нет
• Выбор
• BinaryChoice

Или просто используйте логическое значение.

Я был бы смущен, если бы увидел, что перечисление используется для логического значения. Вы говорите, что:

NOTE: Yes, I could store these as bool (that's how it used to work). My design choice is to be explicit about the Yes/No choice made by the user because they will see this
printed in other contents and I'd like it to be more obvious what the choice was.

Я не понимаю, почему «Да» или «Нет» более «явное», чем истинное или ложное.

ResponseEnum, EResponse или UserResponse в зависимости от ваших соглашений.

Я бы не стал ограничивать себя только «Да» или «Нет», так как в будущем вы, возможно, захотите добавить функциональность, которая также требует ответа «Не уверен».

Вы говорите, что не хотите использовать bool, потому что он будет распечатан, чтобы пользователь мог видеть среди прочего содержимого. Это говорит о том, что проблема не в место хранения, а в отображать. Обязательно представьте истину / ложь как Да / Нет, но нет необходимости создавать для него совершенно новый тип IMO.

Обновлено: в дополнение к предложению вам не использовать перечисление в первую очередь, я настоятельно рекомендую, если вы делать используете перечисление, вы измените порядок или используйте явные значения. Если Yes = 0, No = 1 будет действительно запутанным, если вы когда-нибудь увидите значения как целые числа.

Я думаю, что YesNo в порядке. Рассмотрим такие вещи, как «MB_OK» и «MB_YESNO» ... Я знаю, что это не тип, но все, что говорит само за себя, должно быть в порядке.

Есть ли возможность иметь вариант, отличный от да / нет. Для двух вариантов используйте логическое значение. Попробуйте изменить только область отображения.

Я прочитал ваше обновленное объяснение, но все же считаю, что это плохой выбор. Логические значения существуют как раз для этой цели. ваш отвечает за то, чтобы, когда «они увидят это напечатанным в другом содержимом», выводился соответствующий текст. Это может быть так просто:

Console.WriteLine (_ ("Использование Foo:") + (useFoo? _ ("Да"): _ ("Нет")));

при этом все еще имея полную поддержку локализации. useFoo - это, конечно, параметр, сообщающий функции, использует ли она foo. :)

_ - это сокращение от функции gettext (http://www.gnu.org/software/gettext/), которая доступна для C# (http://www.gnu.org/software/automake/manual/gettext/C_0023.html).

(Юмор - пожалуйста не воспринимай это всерьез ...)

Я удивлен, что это еще никто не предложил:

public enum UserWtf
{
    No,
    Yes,
    FileNotFound
}

Я не вижу смысла в этом перечислении, если не было других значений, кроме Yes и No. Это просто bool. И создание перечисления только для того, чтобы не вводить да или нет, кажется глупым.

Я бы назвал это:

enum Boolean
{
     Yes,
     No
}

Нет, подождите, уже есть встроенный логический тип, который вы можете использовать.

Если ваша единственная причина для использования перечисления здесь заключается в том, что существует удобное преобразование в / из строки, которую вы хотите показать пользователю, тогда вы будете очень сильно укушены, поскольку вы будете делать более сложные вещи. Отделение модели от вида сослужит вам хорошую службу. Прочтите о шаблонах MVC и / или MVVM.

Я также мог бы предположить, что здесь может быть достаточно простого логического значения с некоторыми настраиваемыми атрибутами, которые определяют отображаемые строки для использования вместо «истина» и «ложь». Затем вы можете написать свои собственные методы передачи и из строки, которые будут искать ваши настраиваемые атрибуты.

Я бы вообще не использовал перечисление, просто развернул свой собственный преобразователь типов и использовал логические значения.

Я предполагаю, что есть проблема с отображением значений типа bool. Лучше создать простую оболочку, которая хранит логические значения, позволяя отображать их как Да / Нет или Истина / Ложь.

Я бы посоветовал вам использовать имя, которое указывает значение, для которого установлено значение «Да» или «Нет».

НАПРИМЕР.

public enum Married
{
    YES,
    NO
}

Используйте bool в сочетании с bool.TrueString и bool.FalseString для целей отображения.

Когда мне нужно что-то подобное, я использую слово Flag, как в Flag.Yes, MarriedFlag.No и т. д.

Пример того, когда это полезно: вы знаете, что сегодня есть только значения «Да» и «Нет», но подозреваете, что в будущем могут появиться дополнительные значения (например, «Может быть»).

Я использую OptionalBinaryFilter для:

Да нет все

Но если у вас есть только Yes и No, кажется более подходящим использование Boolean в члене.