C编码样式-线条长度/包装线条[关闭]

Line continuations 在C中不使用,因为显式行终止符( ; )是必需的。

如果你问的是,在风格上,把一条线分成多条线是否是个好主意,这是有争议的。StyleCop规则强制在一行上定义一行,或者每个元素都在单独的行上。我个人认为这是一个很好的指导方针,如果一个80-90字符的编辑器太长,我通常选择将一行完全分解成它的各个部分。

根据新问题进行编辑:

在这种情况下,我将遵循上面的指导方针。就我个人而言,在你的具体案例中,我将把这个放在一行:

SomeMethod(int someInt, Object someObject, String someString, bool someBool) 
{ 
    ... 
} 

这是一个不错的简短的moethod声明,我看不出有任何理由拆分它。只有当一行文本的参数数量和类型长度变得太长时,我才会拆分它。

但是,如果您确实要拆分它,我会为每个参数将其拆分为单独的行:

SomeMethod(
    int someInt, 
    Object someObject, 
    String someString, 
    bool someBool) 
{ 
    ... 
} 

这样,至少很明显它是如何被拆分的,为什么被拆分的,而且开发人员不会意外地跳过一个参数,因为两个参数在一行上。

既然我们已经澄清了这与实际的行连续字符和简单的行包装无关——你告诉我。这是:

IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);

或者这个?

IEnumerable<int> orderIDs = context
    .Customers
    .Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
    .Select(c => c.Orders)
    .SelectMany(o => o)
    .OrderBy(o => o.OrderDate)
    .Select(o => o.OrderID);

你更愿意读哪本书?

我认为在过去的几年里,线路长度的限制逐渐延长(或消失),因为每个人都有宽屏高分辨率显示器,很少再打印出代码。我工作过的所有项目都没有正式的指导方针,我们只是使用常识和一个编辑器窗口宽度的换行符(每个人都使用相同分辨率的基本Eclipse窗口布局)。我认为这个方法没有问题。

我赞成在逻辑点上断线。原因是有助于源代码控制差异化和合并函数。我发现,如果将具有多个元素的语句分解为多行,那么理解这样一个环境中的更改就容易得多。

显示器很大。但是你可以发现你自己在一台笔记本电脑上工作,并在屏幕上的不同窗口中进行合并,在合并中你有基础、源和目标分支。数一数字符:17英寸笔记本电脑上的每个窗口只有55个字符宽。

如果您在远程工作,您会发现水平滚动没有得到很好的优化,并且您可能会对在一行上编写带有15个参数的函数的程序员有一些责备的想法。

所以,考虑一下你在源代码上的所有工作方式,在满足你所有需求的地方划一条线。

几年前我读了达米安康威的 Perl最佳实践 . 下面有一个链接

Perl Best Pracices on Google Books

整个章节都在讨论 代码布局 . 我对代码布局的所有感觉都总结在他的作品中。我强烈推荐这一章。它可以很容易地应用于C。

我一直试图遵守他的规则,无论我用什么语言:C,Java,Perl,JavaScript,VBScript,VB,PHP,…

在这本书中,康威建议使用78列行。我必须承认我违反了规则,坚持到80岁,但我认为没关系。

我已经将这个规则集成到我使用的每个编辑器中(记事本++,Komodo,vi,vim,Visual Studio 2005),以便有一个显示这个限制的视觉指南。

你们中的一些人可能想知道如何显示一个关于vs的指导方针,哈?

嗯,我发现这不太明显。实际上,您必须在注册表中实际创建一个字符串参数。这是我在上面找到的关于它的帖子。希望它有帮助。

Adding a guideline to the editor in Visual Studio

就个人而言,我喜欢能够“看到”一切。再说一次,我有一个相当不错的显示器。但说真的,我喜欢漂亮和小的函数,而不是带有嵌套“if”语句的大型函数。同一行代码。

最后,这取决于个人喜好以及你和你的团队成员的决定。保持一致。下一个看你的代码的人更喜欢可读性。