Java 花括号的约定名称是什么？

我看到很多开发人员在类名或方法下面用大括号编写方法和类，这让我有点困惑。他们遵循什么惯例

Sun认为正确的声明应该是：

// this declaration follows sun's conventions
class Sample extends Object {

    Sample(int i, int j) {
        ....
    }
}

然而，我越来越多地认为这一点（甚至在书中）：

---

我知道一个惯例就是一个惯例，只要你遵循一个惯例，一切都好。我只是在寻找关于后一个声明遵循什么约定的答案？

这是一个称为ANSI样式的标准样式约定。除了Java之外，它在其他语言中也很常见。

请参阅：

Syrion已将其确定为ANSI样式，Sun遵循K&R样式的支撑放置

---

切线：现在我知道被诅咒的样式叫做

< P> >它看起来像是C++中非常流行的，但是我在java中没有看到它经常使用。

< P>我喜欢第二个约定，因为关闭括号将直接在打开的一个下面，因此更容易找到。

第二种约定也是Visual Studio的默认缩进样式（因此在C#

中非常常见）。第一种约定节省了宝贵的空间。不管怎样，括号匹配都是由编辑器完成的。

正如您所说，您已经看到了很多，这难道不使它本身成为一种约定吗，不管该约定是否有单一的来源或名称？它很容易描述，我认为它不需要特别的属性。Wikipedia的页面称之为或ANSI风格，但坦率地说，我已经使用它很多年了，从来没有听说过这个名字，我不认为知道这个名字会改变我的编码方式：）

---

与公共类型和方法的命名等约定不同，大括号位置对使用代码编译版本的开发人员没有影响。。。所以（国际海事组织）不同的项目和公司对此有不同的看法是可以的。。。同样，是否使用空格或制表符、用于缩进的空格数等。我想这就是为什么你在支撑（可能是私人变量）上看到的变化比惯例的其他方面更多。

这可能只是一个城市传说，但我从某个地方回忆起，K&R风格的起源是为了在打印代码时节省空间。。。。当你只有20或24行的时候，节省屏幕空间。现在这已经不再是一个问题了。它现在应该读作“甲骨文清楚地说明…”吗p尽管这个问题显然只是关于大会名称，但令人好奇的是，人们有多么渴望提出自己的观点和偏好，作为离题答案（如和）或作为对这些答案的投票。规则0：不要为小事操心。所有标准支撑位置都同样有效。用你喜欢的任何一种。混搭。它们对可读性没有显著影响。它们不值得列入大会。@Andy:我同意“不要为小事操心”，但仍然不建议“混合搭配”。相反，选择一个并坚持它。即使是很小的东西也会让人分心，从而影响可读性。让我困惑的是，为什么有人会对这个问题投反对票，而不发表评论或投票决定是否结束。这样做的好处是使像diff和merge这样的源代码管理操作更容易。如果有人仅仅因为喜欢一种样式而不喜欢另一种样式而去重新格式化整个文件，那么从源代码管理工具进行合并可能会成为一件非常痛苦的事情。@fruptedWithFormsDesigner:这是在项目中保持一致的好处，但对于跨项目约定来说却不是好处。如果我使用第三方库，即使我将代码包含在自己的源代码管理系统中，我也不会重新格式化它的代码。@Jon恐怕，和其他几个人一样，你在阅读这个问题时碰到了一个软肋。我只是想知道大会的名称。有了这些知识，我将最终挖掘出公约的其他方面（如果没有，也可能没有）。不过，从广义上讲，我同意你的所有回答。@Frankie:我同意，这就是为什么我把第一段从中间移到顶部的原因。我怀疑你得到反应的原因是这个问题的语气——我一开始肯定读到这个问题是批评那些开发者的（特别是因为“太阳清楚地说明了”等等）。只有当我重读这个问题时，我才改变了回答的语气。@Jon yep。作为一个非本地人，我可能听起来有点被动攻击。再加上我更喜欢

Allman缩进样式

。啊!！听起来不错吧？把文字放在你的思想所在的地方？坚持下去。我为你的25万欢呼在这个时代，空间并不宝贵。垂直空间增加可读性。我喜欢用眼睛来匹配大括号，而不必将光标或插入符号放在其中一个大括号上。我当然不是指磁盘空间。使用第一个约定时，您可以在hi-res屏幕上看到更多代码。+1因为您回答了实际提出的问题，而不是对您喜欢的样式进行圣战。@syron非常完美！正是我想要的。谢谢我一直认为这只是微软的风格：）我想补充一点，这就是所谓的“奥尔曼风格”。它被错误地归因于ANSI C文档。

// this declaration follows a convention I cant identify
class Sample extends Object 
{

    Sample(int i, int j) 
    {
        ....
    }
}