什么是不同支撑形式背后的原因?

时间:2008-10-30 06:47:35

标签: php coding-style

我正在阅读Zend Framework coding standards,在类定义应该在下一行,即“一个真正的大括号形式”之后,他们在那里说出大括号。

class MyClass
{
    function....
}

我通常在同一行上有大括号:

class OtherClass {
    function ...
}

将支架放在下一行的原因是什么?或者使用任何其他风格?

9 个答案:

答案 0 :(得分:8)

在线上自己的支撑有助于在视觉上将内部部分与外部部分分开。这样可以更轻松地快速扫描源代码并区分块与周围环境。

另外,在相同的缩进级别使用括号可以让眼睛更容易找到匹配。

答案 1 :(得分:7)

个人偏好确实是唯一真正的“理由”。

答案 2 :(得分:7)

我发现你提到的第一个样式有助于在视觉上将类名与其成员定义相抵消。这有助于我在扫描代码时更轻松地找到类声明的顶部。

答案 3 :(得分:3)

经常引用的原因是:

  • 更容易匹配打开和关闭括号(对于第一个示例)
  • 不要浪费其他一行(这样你就可以在屏幕上放入更多行代码 - 第二个例子)

正如其他人所说:如果您使用第三方代码,请遵循其惯例。如果您使用自己的代码,只需使用您认为更好的样式。

答案 4 :(得分:3)

我认为个人或团队项目的编码风格和命名惯例主要取决于个人品味(尽管团队采用单一编码风格和命名惯例是明智的。)

就个人而言,我喜欢遵循Allman Style惯例,因为它让我快速了解了我的代码和缩进结构。当然,它会在你的代码中花费你一些额外的代码,但我认为这不会影响优势。

关于此事的良好资源是以下维基百科文章:

  

Indent Style

     

Programming Style

     

Naming Conventions

答案 5 :(得分:1)

用户偏好。这真的没什么区别。当我使用PHP开发时,我使用了第二个选项,但现在使用C#,我使用第一个选项。

答案 6 :(得分:1)

关于这个极具主观性的主题,已有几个主题......

有些人对此充满热情,我个人选择了对齐括号的“可读”选项(我不支付我的代码在屏幕上使用的房地产......所以紧凑性对我不感兴趣)但是当我使用另一种风格为项目做贡献,我只使用我的贡献周围的那个 标签大小,硬与软等相同

答案 7 :(得分:0)

真正的原因是在整个代码库中拥有统一的代码。两种风格都有其优点,风格“更好”取决于个人偏好以及在语言和项目中“传统”使用的内容。

如果规定了大括号的样式,请使用它,否则请在到达之前使用正在使用的内容。如果您正在开始一个新项目,请使用通常用于所选语言的内容。

标签与空格相同。

答案 8 :(得分:0)

使用哪种支撑方式有关系吗?不是。在同一项目或源文件上工作的每个人都使用相同的支撑样式是否重要?没有;这不仅无关紧要,而且如果大括号样式从一个编码器到下一个编码器不同,即使在同一个文件中也是如此。

“为什么这段代码确实这样做?”

“我不知道。这是凯文的笔迹。我们去问问他。”