Question

在我们公司的Xmas派对上，我们几乎在一个问题上进行了实际斗争：是否允许在我们的代码中的函数/方法中使用空行（c / c ++ / c＃）。这只是关于单个空行，例如想象代码如：

 private void LoadData()
        {
            if (!loaded)
                return;
            DataStore coll;
            SqlData s = new SqlData();
            if (!s.CallStoredProcedureToStore(out coll, "xy.usp_zzz",...))
                return;

            dataViewXy.BeginUpdate();
            dataViewXy.Items.Clear();
            for(int i = 0; i < coll.RowCount; i++)
            {
                dataViewXy.Items.Add(coll[i]["ID"]);
            }
            dataViewXy.EndUpdate();
        }

这是一个荒谬的混合，只是为了说明情况 - 第一个功能块加载数据，第二个填充某种数据控制，空行将它们分开。

还应该在每个'块'之前写一个评论，但重要的是 for 的人会在该评论之前放置一个空行并且反对伙计们不会。

对于：允许程序员在逻辑上将功能分开，这样可以提高可读性，因为某些视觉提示可以让眼睛跟随

反对：降低可读性，程序员应该使用注释来分隔函数的部分。

我个人的意见是允许在函数中使用空行，因为没有它们，长片代码看起来就像一条永无止境的行流，没有任何关于在哪里找到我正在寻找的东西的线索）

Answer 1

我认为方法体中的空行是代码气味。阅读此博客文章，了解这个主题：An Empty Line is a Code Smell。简而言之，方法体中的空行是一种不好的做法，因为方法不应包含“部分”。方法应该总是做一件事，它的功能分解应该由语言结构（例如，新方法）完成，而不是由空行完成。

Answer 2

这将是一场非常棒的决斗。就像The Good, The Bad, and the Ugly中的最后一个场景，但是方法空白而不是黄金。

老实说，除非你需要经常仔细考虑团队中其他人的代码，否则这根本不重要。就个人而言，我全都是空白，因为它提供了逻辑分组。但对其他人来说可能不一样。哎呀，即使我可能会改变我将事情分组的方式。以前用来理解的分组项目可能不再存在。

无论我们如何对项目进行分组，我认为分组非常重要。我们可以争论为什么空行是不必要的，但事实是大脑一次只能处理有限数量的信息。因此，如果我能够将该函数理解为由三个子组组成，而不是十个语句，则会产生很大的不同。按注释分组对您的IDE来说是主观的。大多数IDE的颜色都比代码的其余部分轻了一些，这给了分离的感觉，但这会变成特定于IDE的。

因此，为了争论这一点，这一切都与分组有关。如果一个类变得太大，我们必须为了可理解性和维护而打破它。类似地，如果方法中的连续代码行变得过于掌握，则必须将其分解为更多方法，或者使用空行换行符进行逻辑分隔。

此外，如果争论无处可去，请抛出一些随机的东西，比如这些空行如何与佛教的虚无概念相关联。

Answer 3

“一刀切”这样的规则不起作用。

支持和反对每个观点都有有效的论据，例如：我可以通过说这些函数应该分解为子例程来反驳你的“长行代码”论点。

但是，这不是重点。

说一个“必须”插入空白行是没有意义的，因为说不能插入空白行。

BW在这些情况下的定律是“使用对你有用的东西”

如果必须解决这个问题，请进行投票，让每个人都同意在投票前遵守投票（即使是你，如果你放弃了）。

那是我的两分钱。

P.S。我的个人意见是空白。

Answer 4

当然，这个问题可能是主观的。

此外，我已经学会了如果方法变得太大而拆分方法，而不是通过删除输入来“压缩”它。

Answer 5

身体上的斗争？在圣诞派对上？听起来很有趣。

当它提高可读性时，我也赞成空格。这也是为什么我也支持排列花括号的部分原因：额外的空格在视觉上引发了代码块。

大多数评论都很混乱，无法提供可读性。如果他们不添加信息来帮助理解代码，那么他们只会妨碍他们。

听起来我会反对“没有空白/添加评论”的人群。

Answer 6

我的经验法则是将所有变量声明放在函数的开头，然后是处理，然后是return语句（如果有的话），每个声明用空行分隔。

int DoSomething(string robot)
{
    int result = 0;

    if (robot == "robot")
        result = 42;

    return result;
}

如果这是一个中等复杂的方法，逻辑上不同的代码块不需要封装在自己的方法中，我也会用空格分隔它们。任何可能等同于“段落”代码的东西都用空行分隔。

我留在方法顶部的///评论块中的大部分评论。

Answer 7

我只是为了空白 - 这是一个微不足道的内存使用量，通过将程序切割成逻辑步骤，极大地提高了代码的可读性。 这不是好评的替代品，但是。我的评论规则是“尽量不要做其他人的代码中令人恼火的事情（这通常证明不是评论 - 简单的'//做X和Y，如果Z表示它是必要的'是一个很好的细节水平个人评论我估计）

我们有足够的存储空间和大小合适的显示器，为什么不使用它来使工作更容易？

大量的空格可以将代码从屏幕上移开，但这会阻碍查看代码并获得良好的概述，因此最好不要过度使用。

与编程中的所有内容一样，这取决于个案判断，个人偏好和一丝温和。

函数/方法中的空行

7 个答案: