Какое хорошее имя для Enum для значений Yes & No

Фон

В приложении командной строки С#, которое я пишу, некоторые параметры имеют "да" и "нет" в качестве возможных значений.

Я сохраняю их вход, используя тип Enum, показанный ниже.

enum YesNo
{ Yes, No
}

Что хорошо - код работает. Нет проблем.

ПРИМЕЧАНИЕ. Да, я мог бы хранить их как bool (как он работал). Мой выбор дизайна должен быть явным в отношении выбора "Да/Нет", сделанного пользователем, потому что он увидит, что это напечатано в других контекстах, и я хотел бы, чтобы это было более очевидно, какой был выбор.

Мой вопрос

  • Кажется странным иметь перечисление под названием "YesNo" - какие-то предложения для лучших имен для перечисления для значений "да" и "нет".

Итак, наконец

Я задал этот вопрос относительно рано в жизни StackOverflow. Это был не поддельный вопрос - у меня действительно была такая ситуация. Я просто подумал, что было бы неплохо использовать его, чтобы посмотреть, что сделает сообщество. Потому что это так, я допускаю несколько странный вопрос.

Во-первых, спасибо всем, кто потратил время на ответ. Я пытаюсь вернуть это с продуманным заключением.

Комментарии к ответам

переключение на bool. Я понимаю вашу мотивацию, но я чувствую, что мне нужно указать, что наличие двоичного выбора (и под этим я подразумеваю выбор между любыми двумя значениями - живыми/мертвыми, замужними/неженатыми и т.д.) не совпадает с логическим выбором между true и false. Мы находим, что программисты переключаются между да/нет и true/false easy - достаточно справедливы. Если бы мой выбор в этом случае был, например, "демократ" или "репликация" (на мой взгляд, надуманный пример), то вы можете видеть возможности для путаницы или, по крайней мере, неловкости. Я действительно думаю, что опция bool действительна в этом случае, но меньше поэтому в других двоичных вариантах.

локализация - отличная точка. В моем конкретном случае это не имело значения - это не было и никогда не будет локализованным, но для других ситуаций это нужно рассмотреть.

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

Было много хороших комментариев, спасибо всем!

17 ответов

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

например.

public enum Married
{ YES, NO
}


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

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


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

ПРИМЕЧАНИЕ. Да, я мог бы хранить их как bool (как он работал). Мой выбор дизайна должен быть явным о выборе Yes/No, сделанном пользователем, потому что они увидят это напечатаны в другом содержании, и я хотел бы, чтобы это было более очевидно, какой был выбор.

Я не вижу, как "Да" или "Нет" больше "явным", чем истинным или ложным.


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

Я бы не ограничился только да или нет, так как в будущем вы можете добавить функциональность, которая также требует ответа Unsure.


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

enum Boolean
{ Yes, No
}

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

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

Я также могу предположить, что здесь может быть достаточно простого логического с некоторыми настраиваемыми атрибутами, которые определяют строки отображения для использования вместо "истинных" и "ложных". Затем вы можете написать свои собственные методы /from string, которые ищут ваши пользовательские атрибуты.


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


Есть ли возможность иметь опцию, отличную от yes/no.For только 2 варианта stick с boolean. Попробуйте изменить только область отображения


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


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


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

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

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

Параметр _ является short для функции gettext (http://www.gnu.org/software/gettext/), который доступен для С# (http://www.gnu.org/software/automake/manual/gettext/C_0023.html).


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

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


EUserAction?

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

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

потому что они увидят, что это напечатано в других контекстах, и я хотел бы, чтобы это было более очевидно, какой был выбор.

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


  • YesNo
  • Выбор
  • BinaryChoice

Или просто используйте boolean.


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

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

public enum UserWtf
{ No, Yes, FileNotFound
}


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


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


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

Да, Нет, Все

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

licensed under cc by-sa 3.0 with attribution.