【问题标题】:What's a good name for an Enum for Yes & No values是和否值的枚举的好名字是什么
【发布时间】:2008-12-22 06:57:32
【问题描述】:

背景

在我正在编写的 C# 命令行应用程序中,一些参数的可能值有“yes”和“no”。

我使用如下所示的 Enum 类型存储他们的输入。

enum YesNo
{
     Yes,
     No
}

这很好 - 代码有效。那里没问题。

注意:是的,我可以将这些存储为 bool(这就是它过去的工作方式)。我的设计选择是明确用户所做的是/否选择,因为他们会在其他上下文中看到这个打印,我希望它更明显的选择是什么。

我的问题

  • 有一个名为“YesNo”的枚举似乎很奇怪 - 有什么建议可以更好地为“yes”和“no”值的枚举命名。

所以最后

我在 StackOverflow 的早期就问过这个问题。这不是假问题——我确实遇到过这种情况。我只是觉得用它看看社区会做什么会很好。因为它是,我承认一个有点奇怪的问题。

首先,感谢所有花时间回复的人。我正试图以深思熟虑的结论来回报这一点。

对答案的评论

切换到 bool。我理解你的动机,但我觉得我需要指出,有一个 二元 选择(我的意思是在任何两个值之间进行选择 - 活着/死去、已婚/未婚等)是不一样 boolean 选择真假。我们发现程序员在是/否和真/假之间切换很容易——这很公平。如果我在这种情况下的选择是“Democrat”或“Replication””(我知道这是人为的例子),那么你会看到混淆或至少尴尬的可能性。我确实认为 bool 选项在这种情况下是有效的,但更少所以在其他二元选择中。

本地化 - 很好。在我的具体情况下,这并不重要 - 这不是而且永远不会被本地化,但对于其他情况,这是需要考虑的。

多于三个选项 - 事实上,后来我不得不添加第三个值来表示用户的有效(在我的应用程序中)条件,特别是 not做出选择。

有很多好的cmets,谢谢大家!

【问题讨论】:

  • 嗯,也许以后会添加“IDontKnow”?哈哈
  • 其实其他参数也可能出现类似情况。示例:是、否、自动是、否、继承
  • 这引出了一个问题:对于包含 {Yes,No,Auto} 或 {Yes,No,Inherit} 等的枚举,什么是个好名字。我实际上使用过前者,发现自己没有更好的替代名称 YesNoAuto,但我讨厌它,每次我不得不使用它时都觉得有点笨。
  • P.S.我使用了 Auto = -1、No = 0 和 Yes = 1。所以也许我应该将其命名为 AutoNoYes。 :)
  • 请不要对自己这样做。坚持使用布尔

标签: c# coding-style naming-conventions naming


【解决方案1】:

您说您不想使用 bool,因为它将被打印出来供用户查看其他内容。这表明问题不在于存储,而在于显示。无论如何将 true/false 呈现为 Yes/No,但 IMO 无需为其创建全新的类型。

编辑:除了建议您首先不要使用枚举之外,我强烈建议如果您确实使用枚举,则更改顺序或使用显式值。如果您最终将值视为整数,那么 Yes=0, No=1 将非常令人困惑。

【讨论】:

  • 您的观察是正确的——枚举对我所做的只是简化了输出生成的一小部分。我可以轻松地创建一个名为 bool_to_yes_no() 的函数 - 但我认为编写 Console.Writeline("paramfoo: {0}", paramfoo ) 会更简单
  • 如果您将存储机制限制为始终直接呈现给用户,我怀疑您将在其他地方陷入困境。我真的会在适当的地方翻译它。作为奖励,i18n 更容易......
  • 布尔答案 = true; string.Format("用户输入{0}", answer ? "Yes" : "No");
【解决方案2】:

我建议您使用一个名称来指示设置为是或否的值。

例如


public enum Married
{
    YES,
    NO
}

【讨论】:

  • 有很多很好的回答,但这个回答最直接。
【解决方案3】:

看到用于布尔值的枚举我会感到困惑。你这么说:

注意:是的,我可以将这些存储为 bool(这就是它过去的工作方式)。我的设计选择 是要明确说明用户做出的是/否选择,因为他们会看到这个
打印在其他内容中,我希望它更明显选择是什么。

我看不出“是”或“否”比“真”或“假”更“明确”。

【讨论】:

  • cmdline-app 的用户不会那么专业——我宁愿他们看到能反映他们输入内容的内容。我会在内部处理映射到 bool 的问题。在这里使用枚举只是一种简单的方法,让我无需付出太多努力就能让最终用户的输出看起来正确。
  • 在程序中管理数据和将其可视化给用户是两件不同的事情。您可以使用布尔值并将其转换为可视化的用户。由于您的枚举不是多语言的,这也为您提供了更多选择。
【解决方案4】:

ResponseEnum 或 EResponse 或 UserResponse 取决于您的约定。

我不会将自己限制为仅是或否,因为将来您可能还想添加需要不确定响应的功能。

【讨论】:

    【解决方案5】:

    我想这样称呼它:

    enum Boolean
    {
         Yes,
         No
    }
    

    不,等等,已经有一个内置的布尔类型可以使用。

    如果你在这里使用枚举的唯一原因是因为你想向用户展示一个字符串的方便转换/从字符串转换,那么当你做更复杂的事情时,你会在轨道上被咬得很厉害.模型与视图的分离将为您提供良好的服务。阅读 MVC 和/或 MVVM 模式。

    我可能还建议使用一些自定义属性的简单布尔值来定义显示字符串来代替“true”和“false”可能就足够了。然后,您可以编写自己的 to/from 字符串方法来查找您的自定义属性。

    【讨论】:

      【解决方案6】:
      • 是否
      • 选择
      • 二元选择

      或者只使用布尔值。

      【讨论】:

      • 这违反了正常的 .NET 命名约定。 “E”通常不用作枚举前缀。
      • 不是枚举吗? 枚举 YesNo { Yes, No }
      • @Burkhard:是的,它是一个枚举。不,这并不意味着它应该以“E”为前缀。它也不应该是复数,因为它不是标志枚举。
      • 嗯,不确定您最后的评论是什么意思,但我的观点是 .NET 中的枚举 不是 通常以 E 为前缀,而您的所有建议是。
      • 不幸的是,我现在无法删除我的反对票。考虑将它删除精神上虽然:)
      【解决方案7】:

      我根本不会使用枚举,只需滚动您自己的类型转换器并使用布尔值。

      【讨论】:

        【解决方案8】:

        我认为 YesNo 很好。考虑诸如“MB_OK”和“MB_YESNO”之类的东西......我知道它不是一种类型,但任何不言自明的东西都应该没问题。

        【讨论】:

          【解决方案9】:

          除了yes/no之外还有其他选项吗?只有2个选项坚持布尔值。尝试单独修改显示区域

          【讨论】:

            【解决方案10】:

            (幽默 - 别把这当回事...)

            我很惊讶还没有人提出这个建议:

            public enum UserWtf
            {
                No,
                Yes,
                FileNotFound
            }
            

            【讨论】:

            • 只有 Paula 会使用 Brilliant!
            【解决方案11】:

            我猜想显示布尔值有问题。 最好创建存储布尔值的简单包装器,以便您将它们显示为是/否或真/假。

            【讨论】:

              【解决方案12】:

              我阅读了您更新的解释,但我仍然觉得这是一个糟糕的选择。布尔值正是为此目的而存在的。 您的有责任确保当“他们将在其他内容中看到此内容”时输出适当的文本。这可能很简单:

              Console.WriteLine(_("Using Foo: ") + (useFoo ? _("Yes") : _("No")));

              同时仍然完全支持本地化。 useFoo 当然是一个参数,告诉函数它是否正在使用 foo。 :)

              _ 是 gettext 函数 (http://www.gnu.org/software/gettext/) 的缩写,可用于 C# (http://www.gnu.org/software/automake/manual/gettext/C_0023.html)。

              【讨论】:

                【解决方案13】:

                EUserAction ?

                您将其描述为一些用户操作。不过,您也可以更具体。该名称允许将来进行一些其他选择。 (名称应该是选择的目的,而不是选择的目的)

                但是,对于您的另一个微妙的问题:

                因为他们会在其他情况下看到这个打印出来,我希望更清楚地看到选择是什么。

                用户看到什么并不重要。数据模型可能与您呈现给用户的内容大不相同。一个布尔值就足够了。未来是否有可能采取更多行动?

                【讨论】:

                • 查看对 Burkhard 的评论。我还认为“用户操作”非常模糊 - 只是名称,您希望看到什么值?
                • 和设计有关。看看他是如何描述它的 :) 此外,这个名称还允许将来有一些额外的选择。名称应该是选择的目的,而不是选择的目的。
                • Moogs - 我明白你在说什么。虽然我不确定在这种情况下它是否对我有帮助(由于与应用程序细节有关的各种原因) - 我认为你的建议对我的代码来说是有意义的。
                • @moogs:我觉得还是不对。 UserChoice 会比 UserAction 更好(他们没有采取行动),但它仍然不是不言自明的——它没有说明他们做出了什么样的选择。如果您无法根据名称猜测枚举的值类型,我会说有问题。
                • @JonSkeet- 如果他更具体地说明它是什么类型的操作(如 SaveDocument 或 KillProcess),那么我可以给出一个更有意义的名称。名字吗?
                【解决方案14】:

                当我需要这样的东西时,我会使用 Flag 这个词,如 Flag.YesMarriedFlag.No 等。

                这很有用的示例:您知道今天只有 Yes 和 No 值,但您怀疑将来可能会有其他值(例如 Maybe)。

                【讨论】:

                  【解决方案15】:

                  我看不出这个枚举的意义,除非除了 Yes 和 No 之外还有其他值。这只是一个布尔值。并且创建一个枚举,这样您就不必输入 yes 或 no 似乎有点愚蠢。

                  【讨论】:

                    【解决方案16】:

                    使用 bool,结合 bool.TrueString 和 bool.FalseString 进行显示。

                    【讨论】:

                      【解决方案17】:

                      我将 OptionalBinaryFilter 用于:

                      是的,不,全部

                      但如果你只有 Yes 和 No,在成员中使用 Boolean 似乎更合适。

                      【讨论】:

                        猜你喜欢
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        相关资源
                        最近更新 更多