括号的位置会影响可读性吗？

发布于 2024-07-21 12:58:31 字数 721 浏览 13 评论 0原文

可能的重复：
if 语句的格式
 是否有最佳的标识编码风格（同一行，下一行）？
编写 stackoverflow 样式“问题”/“标签”的最佳方法' 翻转按钮

public void Method {

}

或

public void Method
{

}

除了个人喜好之外，一种样式相对于另一种样式是否有任何优点？我曾经发誓采用第二种方法，但现在在工作和个人项目中使用第一种方法。

我所说的可读性是指想象这些方法中的代码 - if/else 等......

原文

Possible Duplicates:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions' / 'tags' rollover buttons

public void Method {

}

public void Method
{

}

Besides personal preference is there any benefit of one style over another? I used to swear by the second method though now use the first style for work and personal projects.

By readability I mean imagine code in those methods - if/else etc...

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

饮惑 2024-07-28 12:58:32

在过去，我们曾经使用第一种样式（K & R 样式），因为屏幕较小，代码通常打印在这种称为纸张的东西上。

如今我们有大屏幕，第二种方法（ANSI 风格）可以更轻松地查看括号是否匹配。

请参阅此处和此处了解更多信息。

回复收藏 0 原文

執念 2024-07-28 12:58:32

第一个是行数较少（也许这就是开发 Java 书籍倾向于使用该语法的原因）

第二个是，恕我直言，更容易阅读，因为您总是有两个对齐的括号。

不管怎样，这两种方法都被广泛使用，这取决于你的个人喜好。

回复收藏 0 原文

dawn曙光 2024-07-28 12:58:32

在这个高度情绪化的主题中，我使用 if 语句作为推理的依据。

if (cond) {
   //code
}

只问 else 语句是什么样的？上述内容的逻辑扩展是：-

if (cond) {
   //code   
} else {
   //more code
}

可读吗？我不这么认为，而且它也很丑陋。

行数越多，可读性就越差。因此我会选择你的后一个选择。

I use the if statement as something to reason on in this highly emotive subject.

if (cond) {
   //code
}

by just asking what does the else statement look like? The logical extension of the above is:-

if (cond) {
   //code   
} else {
   //more code
}

Is that readable? I don't think so and its just plain ugly too.

More lines is != less readable. Hence I'd go with your latter option.

回复收藏 0 原文

肩上的翅膀 2024-07-28 12:58:32

就我个人而言，我发现第二个更具可读性（对齐的卷发）。

对于团队来说，采用默认值总是最容易的，而且由于 Visual Studio 和我都同意这一点，这就是我的论点。 ;-)

回复收藏 0 原文

-黛色若梦 2024-07-28 12:58:32

使用第一个选项，您的代码行数将大大减少。 :)

回复收藏 0 原文

轻许诺言 2024-07-28 12:58:31

Google C++ 样式指南建议

返回类型与函数名称在同一行，参数在同一行（如果合适）。
函数如下所示：
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { 
    做一点事（）; 
    ... 
  } 
  

WebKit 编码风格指南建议

函数定义：将每个大括号放在自己的行上。
右：
int main() 
  { 
      ... 
  } 
  
错误：
int main() { 
      ... 
  } 
  

不过，他们建议将其他所有内容都放在同一行上。

GNU 编码标准建议

将 C 函数体的开始大括号放在第一列中非常重要，这样它们就会开始 defun。有几种工具会在第一列中查找开括号来查找 C 函数的开头。这些工具不适用于未采用这种格式的代码。
当开大括号、开括号或开括号位于函数内部时，请避免将它们放在第一列中，这样它们就不会启动 defun。如果您发现将该定义视为 defun 很有用，则启动结构体的开括号可以放在第一列中。
对于函数定义来说，在第一列中以函数名称开头也很重要。这有助于人们搜索函数定义，也可能有助于某些工具识别它们。因此，使用标准 C 语法，格式如下：
静态字符 * 
  连接（字符*s1，字符*s2） 
  { 
    ... 
  } 
  
或者，如果您想使用传统的 C 语法，请按如下所示格式化定义：
静态字符* 
  concat (s1, s2) /* 名称从此处的第一列开始 */ 
       字符*s1，*s2； 
  { /* 此处第一列中的左大括号 */ 
    ... 
  } 
  

如您所见，每个人都有自己的意见。就我个人而言，我更喜欢 Perl 式的大括号 on-same-line- except-for-else，但只要编写代码的每个人都能合作，这真的不重要。

Google C++ Style Guide suggests

Return type on the same line as function name, parameters on the same line if they fit.
Functions look like this:
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}

WebKit Coding Style Guidelines suggests

Function definitions: place each brace on its own line.
Right:
int main()
{
    ...
}
Wrong:
int main() {
    ...
}

They suggest braces-on-same-line for everything else, though.

GNU Coding Standards suggests

It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.
Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won't start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.
It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this:
static char *
concat (char *s1, char *s2)
{
  ...
}
or, if you want to use traditional C syntax, format the definition like this:
static char *
concat (s1, s2)        /* Name starts in column one here */
     char *s1, *s2;
{                     /* Open brace in column one here */
  ...
}

As you can see, everybody has their own opinions. Personally, I prefer the Perl-ish braces-on-same-line-except-for-else, but as long as everybody working on the code can cooperate, it really doesn't matter.

回复收藏 0 原文