如何避免浪费屏幕空间编写稀疏的 C# 代码？

Question

普遍接受的格式化 C# 代码的方式似乎如下：

namespace SomeNamespace
{
    namespace SomeSubNamespace
    {
        class SomeClass
        {
            void SomeFunction()
            {
                using (var someFile = new StreamWriter(somePath))
                {
                    try
                    {
                        lock(someCriticalSection)
                        {
                            using (var someDisposableThing1 = new DisposableThing())
                            {
                                DoSomething();                            
                                using (var someDisposableThing2 = new DisposableThing())
                                {
                                    lock(someOtherCriticalSection)
                                    {
                                        DoSomethingMore();
                                    }
                                }
                            }
                        }
                    }
                    catch(Exception e)
                    {
                        Log(e);
                    }
            }
        }
    }
}

这浪费了大量的水平和垂直屏幕空间。我肯定不是第一个注意到的人。我的问题是：您是否接受它，或者您是否开发了不同的格式样式以避免过多的空白？

PS：请注意，我什至还没有使用单个 if 语句！

Answer 1

我倾向于编写小类、短方法和小级别的嵌套。您不仅可以看到屏幕上的所有内容，而且代码也更好！

Answer 2

我有一个 24 英寸宽屏显示器。比起回收空间，我更喜欢“漂亮的打印”。压缩的、挤在一起的代码很难阅读，而且会伤害我的大脑。

Answer 3

如果我要尝试/捕捉某些东西，我会与任何相邻的 using 块结合起来。同样，我会聚合命名空间，所以更接近：

namespace SomeNamespace.SomeSubNamespace
{
    class SomeClass
    {
        void SomeFunction()
        {
            StreamWriter someFile;
            try
            {
                someFile = new StreamWriter(somePath);

                lock(someCriticalSection)
                {
                    using (var someDisposableThing1 = new DisposableThing())
                    {
                        DoSomething();                            
                        using (var someDisposableThing2 = new DisposableThing())
                        {
                            lock(someOtherCriticalSection)
                            {
                                DoSomethingMore();
                            }
                        }
                    }
                }
            }
            catch(Exception e)
            {
                Log(e);
            }
            finally
            {
                if( someFile != null )
                {
                     someFile.Dispose();
                }
            }
        }
    }
}

Answer 4

也不认为它看起来那么糟糕;)
然而，制作更短的函数确实是一个重点。 的操作，那就太好了

if (condition)
{
   // bla
}
else
{
  // blub
}

特别是，如果您可以执行诸如替换之类

void someFunction()
{
  if (condition)
  {
    // bla
    return
  }
  // blub
}

Answer 5

using 语句非常方便，但如果代码变得难以阅读，您可以不使用它：

namespace SomeNamespace.SomeSubNamespace
{
    class SomeClass
    {
        void SomeFunction()
        {
            StreamWriter someFile = new StreamWriter(somePath);
            DisposableThing someDisposableThing1 = null;
            DisposableThing someDisposableThing2 = null;

            try
            {
                lock (someCriticalSection)
                {
                    someDisposableThing1 = new DisposableThing();
                    DoSomething();
                    someDisposableThing2 = new DisposableThing();
                    lock (someOtherCriticalSection)
                    {
                        DoSomethingMore();
                    }
                }
            }
            catch (Exception e)
            {
                Log(e);
            }
            finally
            {
                // requires SafeDispose extension method
                someFile.SafeDispose();
                someDisposableThing1.SafeDispose();
                someDisposableThing2.SafeDispose();
            }
        }
    }
}

Answer 6

我在代码块的开头行看到了开括号，如下所示：

namespace SomeNamespace { 
    class SomeClass {
        void SomeFunction() {
            using (var someFile = new StreamWriter(somePath)) {
                try {
                    lock(someCriticalSection) {
                        using (var someDisposableThing1 = new DisposableThing()) {
                            DoSomething();                             
                        }
                    }
                } catch(Exception e) { 
                    Log(e); 
                } 
            }
        } 
    } 
} 

更少的空间，但我认为它很难看。

Answer 7

我同意其他答案，我基本上接受它——对于我的团队来说，我们要么有高分辨率显示器，要么有双显示器（或两者都有），所以我们不像在 800x600 上开发。

但要记住的一件事是，如果使用实际间距，制表符会更好，因为有些开发人员使用 2 个空格作为制表符，有些是 4 个，有些是 6 个。因此，虽然格式化代码在某个开发人员的 IDE 上可能看起来不错，但穿在别人身上可能不太好看。 （我已经看到了一些可怕的结果。）

VS2010 有一个来自扩展管理器的很好的插件，称为生产力工具，它可以检测文件中何时混合有制表符和空格，并允许您将所有内容转换为制表符或空格（“修复混合选项卡”）。它确实有助于清理您的文件（即使它看起来没有任何作用！）。如果您在团队之间共享代码，那就太好了。

Answer 8

使用 CodeRush ，
它会让你的代码导航变得更好

你会得到这样的东西

Answer 9

除了其他人在这里所说的之外，我为减轻影响所做的一件事是使用比例间距字体。文本更易读，但宽度不够。它还迫使你使用制表符而不是空格来对齐（当然，这就是上帝首先给我们制表符的原因）

我个人使用 Comics Sans MS，但这确实让同事们抓狂......

Answer 10

1. 我不经常看到以这种方式嵌套的命名空间 - 也许它会发生，而不是我工作的地方
2. 和我生活的地方。并且大多数情况下不要编写如此深层嵌套的代码。拥有更短的方法或更少嵌套的方法肯定会减少水平空白问题，并且将方法分解成更小的部分意味着您可以在给定的垂直空间中获得更重要的信息。

Answer 11

让我这样解释一下。如果您确实碰巧遇到了与上面显示的一样深的嵌套代码构造，那么问题可能不是格式而是您的代码结构。

您应该考虑看看这个：Martin Fowler 的重构

提取方法您改进的不仅仅是“浪费”的屏幕空间，但也显着提高了可读性；）

另一种解决方案始终是：在 Visual Studio 中 Alt + Shift + Enter 进入全屏模式

Answer 12

好吧，我买了一台高清显示器；）

但是除了使用更少的缩进之外，处理它的唯一方法是将一些代码移动到他们自己的方法中。

Answer 13

工具>选项>文本编辑器>所有语言>标签>缩进尺寸> 1
这不是一个很好的解决方案...:P

Answer 14

您应该阅读 Bob Martin 的简洁代码。它有助于解决这个问题。在本例中，SomeFunction() 执行不止一件事。将它所做的每件事分解为它自己的方法。

 namespace SomeNamespace.SomeSubNamespace
 {
    class SomeClass
    {
        void WriteToFile()
        {
            using (var someFile = new StreamWriter(somePath))
            {
                lock(someCriticalSection)
                {
                   ExecuteCriticalSection();
                }
            }
        }
        void ExecuteCriticalSection()
        {
            using (var someDisposableThing1 = new DisposableThing())
            {
            DoSomething();
            ExecuteFinalCriticalSection();
            }   
        }

        void ExecuteFinalCriticalSection()
        {
            using (var someDisposableThing2 = new DisposableThing())
            {
            lock(someOtherCriticalSection)
                {
                DoSomethingMore();
                }
            }
        }
    }
}

另外，不要捕获System.Exception；你永远不知道什么会失败，并且你不应该尝试捕获你无法处理的异常。让它们冒泡然后惨死。