支架放置是否会影响可读性？

Question

可能的重复:
if语句的格式
是否有最佳的标识编码风格(同一行,下一行)？
编写stackoverflow样式'问题'/'标签'翻转按钮的最佳方法

public void Method {

}

要么

public void Method
{

}

除了个人喜好之外,还有一种风格比另一种风格更有益吗？我曾经用第二种方法发誓虽然现在使用第一种方式进行工作和个人项目.

可读性我的意思是想象那些方法中的代码 - if/else等......

Answer 1

谷歌C++风格指南建议

返回与函数名称相同的行上的类型,如果适合则返回同一行上的参数.

函数看起来像这样:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}

WebKit编码风格指南建议

函数定义:将每个括号放在自己的行上.

对:

int main()
{
    ...
}

错误:

int main() {
    ...
}

不过,他们建议在其他所有方面使用相同的括号.

GNU编码标准表明

在第一列中放置启动C函数体的开括号非常重要,这样它们就可以开始定义.有几个工具在第一列中查找开括号以找到C函数的开头.这些工具不适用于没有格式化的代码.

当它们在一个函数内部时,避免在第一列中放置开括号,开括号或开括号,这样它们就不会开始定义.如果您发现将该定义视为defun有用,那么启动结构体的开括号可以放在第一列.

函数定义在第一列中启动函数名称也很重要.这有助于人们搜索功能定义,也可以帮助某些工具识别它们.因此,使用标准C语法,格式如下:

static char *
concat (char *s1, char *s2)
{
  ...
}

或者,如果要使用传统的C语法,请按如下格式定义:

static char *
concat (s1, s2)        /* Name starts in column one here */
     char *s1, *s2;
{                     /* Open brace in column one here */
  ...
}

如你所见,每个人都有自己的看法.就个人而言,我更喜欢Perl-ish braces-on-same-line-except-for- else,但只要每个参与代码的人都可以合作,那真的没关系.

Answer 2

我认为这是完全主观的,但是,我认为为您的团队建立代码标准并让每个人都使用相同的风格非常重要.这就是说我喜欢第二个(并且让我的团队使用它)因为当它不是你的代码时它似乎更容易阅读.

Answer 3

在过去,我们习惯使用第一种风格(K&R风格),因为屏幕较小,代码经常印在这种称为纸张的东西上.

这些天我们有大屏幕,第二种方法(ANSI风格)让你更容易看到你的括号是否匹配.

有关更多信息,请参阅此处和此处.