Skip to main content
Commonmark migration
Source Link

#A Bit About Regions

A Bit About Regions

#A Bit About Regions

A Bit About Regions

Source Link
RubberDuck
  • 30.9k
  • 6
  • 71
  • 174

#A Bit About Regions

Some people hate them. I'm not one of those people. I think that used correctly, they're a great thing. For example, I think this is a wonderful use of a Region.

    #region Method WriteLine...
    public static void WriteLine(string format, int min = 50, int max = 100, params object[] args)
    {
        Write(format, min, max, args);
        Console.WriteLine();
    }

    public static void WriteLine(string format, BootstrapStyle style, BootstrapType type, params object[] args)
    {
        Write(format, style, type, args);
        Console.WriteLine();
    }

    public static void WriteLine(string format, int min, int max, BootstrapStyle style, BootstrapType type, params object[] args)
    {
        Write(format, min, max, style, type, args);
        Console.WriteLine();
    }
    #endregion

This is beautiful. It makes sense to group all of the different WriteLine overloads together. This is a good use of regions.

Unfortunately, you have some instances where it's not so good.

Here, for example, you've wrapped a single method inside of a region. Why? What does this do for us other than clutter the code?

    #region Method MessageBox
    public static void Popup(string format, string caption, params object[] args)
    {
        MessageBox.Show(String.Format(format, args), caption);
    }
    #endregion

To make it worse, the "comment" in the region doesn't match the method. One says it's a MessageBox while the name of the method is Popup. I understand why. You didn't want to muck around with a namespace conflict, which is okay. Although, I might have just called it ShowMessageBox and been done with it myself. Popup is a noun, but you're taking an action here. I digress however, because there's also this:

    #region Method Controller...
    public static void CloseBox(bool enable)
    {
        EnableMenu(GetSystemMenu(GetConsoleWindow(), enable), SC_CLOSE, MF_ENABLED);
    }

    public static void MaximizeBox(bool enable)
    {
        EnableMenu(GetSystemMenu(GetConsoleWindow(), enable), SC_MAXIMIZE, MF_ENABLED);
    }

    public static void MinimizeBox(bool enable)
    {
        EnableMenu(GetSystemMenu(GetConsoleWindow(), enable), SC_MINIMIZE, MF_ENABLED);
    }
    #endregion

Which in and of itself wouldn't be such a terrible use of regions. These all belong to the same logical group of methods, but now you're not being consistent with how you're using them. Are you using regions to logically group concepts, or overloads?? I suppose this is part of the reason so many people hate them.

All in all though, it's not bad. I've seen much worse and I might even venture to say that you've used them rather well, all in all. Just be careful with it. It's easy to let your regions get away from you. It's easy to just keep shoving things inside of them when you should really be extracting logic and creating new classes. I don't feel that's the case here, but I do feel it's worth mentioning.


P.S. Really cool little project. Thanks for sharing.