将大括号放在与单行“if”语句的语句相同的行上是不是很糟糕？
所以我知道，总是包括if，for等花括号，这是一种好的做法，即使它们是可选的，如果只有一个后面的语句，因为它更容易意外地做类似的事情：
if(something == true) DoSomething(); DoSomethingElse(); 如果你没有把括号快速编辑代码。
虽然这样的事情怎么样：
if(something == true) { DoSomething(); }
这样你仍然占用更少的线（IMO提高了可读性），但仍然不太可能从上面意外地犯错误？
我问，因为我不相信我以前见过这种风格的if或循环，但我确实看到它用于C＃属性中的getter和setter，如：
public string Name {get;set;}
不要问什么是最好的，因为这太主观了，而只是这是否被认为是可接受的风格，如果没有，为什么不。
当我遇到一行if语句时，我通常跳过curl并将所有内容保持在同一行：
if (something == true) DoSomething();
它快速，简单，节省空间。
代替：
if(something == true) { DoSomething(); }
做这个：
if(something == true) { DoSomething(); }
我倾向于在自己的行上打开括号，如下所示：
if (condition) { statement; statement; }
所以看到类似的东西：
if (condition) statement; statement;
立即脱颖而出。 如果我只有一个陈述，我就把它留作
if (condition) statement;
如果我有一个额外的声明要添加，请将括号放入。 我真的没有看到任何混淆的余地。
将语句放在与条件相同的行上是一个坏习惯，因为在调试时，大多数调试器将整个事件计为一行。 （我意识到在C＃中并非如此）。
如果你在团队中工作，你需要提出一个标准。
我个人喜欢这样做：
if(foo) DoSomething();
要么
if(foo) DoSomething();
我没有看到没有牙套的问题。 人们引用的原因，你提到的关于在下面的行中添加另一个陈述的那个，是我从来没有参与过的那个。
很多人建议将两者放在一条线上。 这可能会增加可读性，但代价是我认为调试能力下降。 我已经通过这种方式编写了大量代码，因此调试起来比较困难。
一些调试器和IDE可能能够跨越单行的两个部分， if -statement并清楚地显示条件是否为真，但许多其他调试器可能将其视为单行，因此很难确定是否为if -statement被调用了。
例如，用于C ++代码的VS2008调试器将作为单行执行此操作，因此很难确定是否调用了Foo（）。
if (a==b) { Foo(); }
就个人而言，我喜欢我所有的块都有相同的模式。 我总是使用ifs的大括号，他们总是开始新的一行。 我喜欢自动定义放置{get;的公共属性的习语。 组; 在同一条线上。 我只是觉得所有的块都以自己的支撑开始，提高了可读性。 正如其他人所指出的那样，如果你跨越线路，它也会使调试器更清晰。
如果你不同意，那也没关系，但正如其他人所说的一致。 为此，您可能希望在您和您的同事之间共享“代码格式”设置，以便自动格式化使每个人都能保持一致。
我会做：
if (something) { DoSomething(); }
和
public string MyProperty { get; set; }
我不明白为什么不。 我也用它来做短function。
在进攻风格方面，它远比无法形容的好：
if (something== true) { DoSomething(); }
但是，虽然我们的主题是风格，但它是
if (something)
和
if (!something)
决不
if (something== true)
要么
if (something== false)
这样你仍然占用更少的线（IMO提高了可读性）
我不同意减少换行次数会增加可读性。 代码的布局应该使其结构更加可见，而不是隐藏它。
我昨天在处理由其他人编写的代码时遇到了这个问题。 原始代码是：
if (something == true) DoSomething();
在调用DoSomething()之前我想要一个调试打印。 我本能地做什么
if (something == true) print("debug message"); DoSomething();
但这会使if仅适用于调试消息，而DoSomething()将被无条件地调用。 这就是为什么我宁愿使用大括号，以便本能编辑最终成为：
if (something == true) { print("debug message"); DoSomething(); }
新行，缩进，间距，对齐等forms的空白是排版的一个重要方面，广泛用于提高文章，书籍和网站中文本的可读性。 不确定为什么它不会对代码的可读性应用相同的内容。
话虽如此，你和你的团队使用你的风格没有任何问题。 只要你们所有人都同意的话。
那里没有问题……事实上，如果您尝试自动格式化，Visual Studio将不会将该代码放在它自己的行上。 所以，如果那对你更具可读性……你很好。
如果您真的想保存代码行，可以像这样输入：
if(something == true) { DoSomething(); }
或者这个，没有大括号
if(something == true) DoSomething();
我建议你喜欢斯蒂芬和尼古拉斯曼库索说。
使用：
if(something) { DoSomething(); }
带或不带支架。 一旦你开始使用奇怪版本的“if”语句，你就会开始看到你的同事以一种奇怪的方式看你的代码。
我通常使用一个衬垫进行validation。
例：
if( param1 == null ) throw new ArgumentNullException("param1");
只要你保持一致就不应该成为一个问题。 在以前的公司，这是典型的情况，但在我现在的公司，他们更喜欢在单独的线上。
只要你始终如一地做到这一点，并确保每个处理代码的人都知道你是如何做到的，那么你做什么并不重要。
只要做你觉得最舒服的事情，然后确保每个人都知道总是那样做。
实际上，我更喜欢
if (something == true) if (something == false)
过度
if (something) if (!something)
对我来说，感叹号一目了然很难看，所以容易错过。 但请注意，当我在Python中编码时，我几乎总是喜欢：
if something: if not something:
除非我想区分无，例如空列表。
我偶尔喜欢这样做
if(obj != null) obj.method();
但这是一种内疚的乐趣……我认为它不会使代码更具可读性，所以为什么不遵循其他人正在使用的模式。 我认为非常重要的一个例外是当你展示它是如何成为更大模式的一部分时，并帮助用户更容易地看到模式：
public executeMethodOn(String cmd) { CommandObject co; if("CmdObject1".equals(cmd)) co=new CmdObject1(); if("CmdObject2".equals(cmd)) co=new CmdObjec21(); co.executeMethod(); }
它使模式更加明显，并帮助尝试插入新function的人看到它需要去的地方。
也就是说，如果你有这样的模式，你可能做错了。 我不得不在一个没有reflection的系统上做这个，但我尝试了很难解决它，如果我有reflection，那就太棒了。
我通常使用单行ifs执行此操作：
if($something) { do_something(); }
一个例外（我做Perl，不确定C＃中是否允许这种样式）是用于循环控件，我使用倒置的一行样式：
THING: for my $thing (1 .. 10) { next THING if $thing % 3 == 0; }
通过良好的语法着色，可以使这些线条突出显示。
你们都错了！!!!!! 😉
幸运的是，只需更换每个文件中的最后一个花括号，VS就可以将所有的疯狂重新格式化为我个人认可的格式。
空白是一种风格的东西。 由于我们有不同的阅读风格和学习风格，所以你的工作方式无关紧要。 这些工具可以让我们来回切换。 我注意到的唯一不足之处是跟踪源代码管理中的更改所需的代价。 当我将K＆R样式文件重新格式化为更加理智的格式（我的意见）并检查更改回源代码控制时，它几乎显示每行都已更改。 那是一种痛苦。 但是许多diff实用程序可以忽略空白更改（尽管大多数只在一行上，而不是跨越行）。 这是一个问题。 但不是表演的塞子。
C在格式化问题上给予了很大的自由，因此将它们放在同一行或不同的行中与编译目的无关。
结果，“它会不好”只是指编码惯例。 这取决于具体情况。 如果您在团队中工作，最好向其他人询问他们的想法并提出标准的格式化风格。 如果没有，那真的取决于你。
所以，如果你认为它更好，那就继续吧。 如果没有，那就不要了。 它真的那么简单（除非你使用一个强加一些样式约定的IDE）
我更喜欢令人难以置信的语法：
if (true == something) { doSomething1(); }
是的，这就是K＆R做到的方式……是的，我回到那么远……是的，这对我来说已经足够了。 这意味着即使我这样做，我也会得到通用语法：
if (-1 == doSomething()) { doSomethingElse(); }
无论它们包含的代码行数是多少，我都将花括号括起来。 我被“需要添加一行测试代码”所困扰，并且多次错过了花括号的缺失。
我总是与左边的文字进行比较。 这避免了“测试分配”错误（例如if（something = true）{…}）。
“（某事= =真）”的可移植性没有比在布尔比较中使用重载值集合意味着“真”和“假”的危险更大的危险 – 但它是一种不同的危险。 您是否使用将“空”（和/或零和/或NULL和/或空格）视为“真”或“假”的语言编写？ 我更喜欢一种对每种情况都安全的惯例……因为我很懒。