把所有的枚举都放在一个地方好吗?

一般来说,按模块化排列定义比按种类排列要好。

我个人认为这不是个好主意。我更喜欢将枚举保存在自己的文件中(每个已定义的枚举一个文件),就像类一样。这使我更清楚地知道,如果我正在寻找一个类型,我应该去哪里。我对待枚举就像对待一个类或结构,或任何其他命名空间范围的类型,这对我来说意味着每个文件有一个类型。

但是,编译后的IL没有技术上的区别。这其实更像是个人的、组织的策略。

好吧,你可以对所有的委托类型,所有的类,所有的结构应用同样的推理。

通过根据它们对编译器的重要性对它们进行分组,您将失去以对编译器有意义的方式对它们进行分组的机会 你 . 编译器已经知道如何根据它们在语言中的含义来处理它们。

就我个人而言,当我想找到与“Parser”相关的声明而不是“Configuration Dialog”时,我会去保存该特性代码的地方。根据我使用的语言特性,我不必看五个不同的地方。

我们通常有一个完整的项目,集合了我们所有的 常量、枚举和助手方法。

对 ,我建议将它们放在一个中心,方便访问的位置。

这将允许您轻松地从其他程序集访问程序集,从而避免循环引用。

我更倾向于名称空间组织。VisualStudio使导航到对象的声明变得太容易了。对我来说,在MyData名称空间中有一个与数据库/数据访问相关的enum比一些通用的enum名称空间更有意义,因为我不太关心文件名。

我是一个java开发人员,但我想我也可以在这里回答。。。

对我来说这不是个好主意。就像丹尼尔·埃尔威克说的,你可以在课堂上做同样的事情。。。您可以在一个文件中处理整个应用程序,其中包含许多内部类(我假设在C中,就像在Java中一样,您可以有内部类……),但无论如何您都不会这样做。。。

枚举有时可以是更复杂的结构,它可以有属性。。。

Java中的一个(非常)简单的例子:

public enum JobPriority {
    HIGH(5),
    MEDIUM_HIGH(4),
    MEDIUM(3),
    MEDIUM_LOW(2),
    LOW(1)
    ;
    private int level;
    JobPriority(int level) {
        this.level = level;
    }
    public int getLevel() {
        return level;
    }
}

我在一个很大的法国网站工作,我们的枚举结构要复杂得多。。。如果我们把所有的枚举都放在一个文件里,这个文件会有几百行。。。

因此,如果您的应用程序很小,枚举结构也不复杂,那么您可以将它们全部放在一个文件中。

但是您更愿意将复杂的枚举放在enum名称空间(java包)的单个文件中,并在应用程序的每个功能部分需要时创建一个enum名称空间。对于简单枚举,为什么不在给定命名空间的公共枚举文件中添加then(您可以有多个公共枚举文件)。不知道这是不是个好习惯。

如果你需要找到一个枚举,你的IDE也许会提供快速的类搜索来轻松找到枚举no?您还可以使用xxxEnum.cs作为所有枚举的后缀来区分它们(还可以通过类名*Enum快速查找它们)。

在我正在开发的javawebapp中(大约200万行代码,数百个枚举),我们可以在eclipseide中通过ctrl+shift+R+*Enum这样的快捷方式轻松找到枚举。它比普通枚举文件快得多:)

有些代码文件名会立即给我带来危险。随着 utils.cpp , helpers.vb (或诸如此类)如果我看到 enums.cs 我马上就怀疑一个软件是否与枚举过度耦合了。

枚举应该谨慎使用,并在与其关联的叶(最少类型耦合)类型附近声明。

我经常看到大型系统由于共享枚举而过度耦合。不久,就会有人想出一个好主意,枚举所有数据库主键。