您会在长开关/枚举声明中使用区域吗?

发布于 2024-07-25 09:19:41 字数 703 浏览 5 评论 0原文

我最近发现自己需要(是的,需要)在 C# 代码中定义荒谬的长 switch 语句和 enum 声明,但我想知道人们认为最好的是什么将它们分成逻辑小节的方法。 在我的情况下,枚举值和案例(基于枚举值)都有相当清晰的分组,但我有点不确定如何在代码中反映这一点。

请注意,在我的代码中,我大约有 5 组,每组有 10 到 30 个枚举值/案例。

我可以设想的三个模糊合理的选项是:

  1. 在声明中围绕所有逻辑组/枚举值定义 #region 块(可以选择用空行分隔)。
  2. 用其名称注释每个组,每个组名称注释前有一个空行。
  3. 不执行任何操作 - 只需将开关/枚举保留为大量案例/值列表即可。

你更喜欢哪一个? 你会分开对待枚举和开关吗?(这对我来说似乎有点奇怪。)现在,我不会说这个问题有任何正确/错误的答案,尽管我仍然很有兴趣听到普遍共识的观点是什么。

注 1: 不幸的是,这种情况是不可避免的(与 switch 类似),因为我正在尝试编写一个词法分析器(标记器) ,因此,出于多种原因,这似乎是最合理的方法。

注2:我完全意识到关于是否在通用代码中使用区域(主要用于构造类)的问题已经存在几个重复的问题,但我觉得我在这里的问题更加具体和尚未得到解决。

I've recently found myself needing (yes, needing) to define absurdly long switch statements and enum declarations in C# code, but I'm wondering what people feel is the best way to split them into logical subsections. In my situation, both the enum values and the cases (which are based on the enum values) have fairly clear groupings, yet I am slightly unsure how to reflect this in code.

Note that in my code, I have roughly 5 groups of between 10 and 30 enum values/cases each.

The three vaguely sensible options I can envisage are:

  1. Define #region blocks around all logical groups of cases/enum values within the declaration (optionally separated by blank lines).
  2. Comment each group with it's name, with a blank line before each group name comment.
  3. Do nothing whatsoever - simply leave the switch/enum as a huge list of cases/values.

Which do you prefer? Would you treat enums and switches separately? (This would seem slightly odd to me.) Now, I wouldn't say that there is any right/wrong answer to this question, though I would nonetheless be quite interested in hearing what the general consenus of views is.

Note 1: This situation where I might potentially have an extremely long enum declaration of 50/100+ values is unfortunately unavoidable (and similarly with the switch), since I am attempting to write a lexer (tokeniser), and this would thus seem the most reasonable approach for several reasons.

Note 2: I am fully aware that several duplicate questions already exist on the question of whether to use regions in general code (for structuring classes, mainly), but I feel my question here is much more specific and hasn't yet been addressed.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

昔梦 2024-08-01 09:19:42

当然,将这些事情划分出来。 它们可能不会发生太大变化,当它们发生变化时,您可以扩展该区域,进行更改,折叠它,然后继续处理文件的其余部分。

它们的存在是有原因的,利用它们为你带来优势。

Sure, region those things up. They probably don't change much, and when they do, you can expand the region, make your changes, collapse it, and move on to the rest of the file.

They are there for a reason, use them to your advantage.

总以为 2024-08-01 09:19:42

您还可以有一个 Dictionary<[your_enum_type], Action> (或 Func 而不是 Action)或类似的东西(考虑到您的函数具有类似的签名)。 然后你可以不使用开关,而是:

        switch (item)
        {
            case Enum1: func1(par1, par2)
                break;
            case Enum2: func2(par1, par2)
                break;
        }

你可以有类似的东西:

public class MyClass
{
    Dictionary<int, Action<int, int>> myDictionary;
    //These could have only static methods also
    Group1Object myObject1;
    Group2Object myObject2;

    public MyClass()
    {
        //Again, you wouldn't have to initialize if the functions in them were static
        myObject1 = new Group1Object();
        myObject2 = new Group2Object();
        BuildMyDictionary();
    }

    private Dictionary<int, Action<int, int>> BuildMyDictionary()
    {
        InsertGroup1Functions();
        InsertGroup2Functions();
        //...
    }

    private void InsertGroup2Functions()
    {
        myDictionary.Add(1, group2.AnAction2);
        myDictionary.Add(2, group2.AnotherAction2);
    }

    private void InsertGroup1Functions()
    {
        myDictionary.Add(3, group1.AnAction1);
        myDictionary.Add(4, group1.AnotherAction1);
    }


    public void DoStuff()
    {
        int t = 3; //Get it from wherever
        //instead of switch
        myDictionary[t](arg1, arg2);
    }
}

You could also have a Dictionary<[your_enum_type], Action> (or Func instead of Action) or something like that (considering your functions have a similar signature). Then you could instead of using a switch, instead of:

        switch (item)
        {
            case Enum1: func1(par1, par2)
                break;
            case Enum2: func2(par1, par2)
                break;
        }

you could have something like:

public class MyClass
{
    Dictionary<int, Action<int, int>> myDictionary;
    //These could have only static methods also
    Group1Object myObject1;
    Group2Object myObject2;

    public MyClass()
    {
        //Again, you wouldn't have to initialize if the functions in them were static
        myObject1 = new Group1Object();
        myObject2 = new Group2Object();
        BuildMyDictionary();
    }

    private Dictionary<int, Action<int, int>> BuildMyDictionary()
    {
        InsertGroup1Functions();
        InsertGroup2Functions();
        //...
    }

    private void InsertGroup2Functions()
    {
        myDictionary.Add(1, group2.AnAction2);
        myDictionary.Add(2, group2.AnotherAction2);
    }

    private void InsertGroup1Functions()
    {
        myDictionary.Add(3, group1.AnAction1);
        myDictionary.Add(4, group1.AnotherAction1);
    }


    public void DoStuff()
    {
        int t = 3; //Get it from wherever
        //instead of switch
        myDictionary[t](arg1, arg2);
    }
}
时间海 2024-08-01 09:19:42

我会把它作为一个巨大的案例/值列表。

I would leave it as a huge list of cases/ values.

千鲤 2024-08-01 09:19:42

如果某些情况下具有相同的代码块,则使用策略设计模式可以删除 switch 块。 这可以为您创建很多类,但会显示它实际上有多复杂,并将逻辑拆分为较小的类。

If there are some cases that have the same code block, using the Strategy design pattern, could remove the switch block. This can create a lot of classes to you, but will show how complex it really is, and split the logic in smaller classes.

椵侞 2024-08-01 09:19:42

摆脱枚举并将它们变成对象。 然后,您可以调用对象上的方法,并使代码保持独立、可维护,而不是一场噩梦。

在极少数情况下,您实际上需要使用枚举而不是对象,并且没有人喜欢长 switch 语句。

Get rid of the enums and make them into objects. You could then call methods on your objects and keep the code separated, maintainable, and not a nightmare.

There are very few cases when you would actually need to use an enum instead of an object and nobody likes long switch statements.

夏天碎花小短裙 2024-08-01 09:19:42

对于使用区域的人来说,这是一个很好的捷径。

当我尝试在 VS 中按全屏时,我正在 Eclipse 和 Visual Studio 之间切换

Ctrl-M-M

,你瞧,该区域关闭并扩展了!

Here's a good shortcut for people who use regions.

I was switching between Eclipse and Visual Studio when I tried to go full screen in VS by pressing

Ctrl-M-M

and lo and behold, the region closed and expanded!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文