logo标签列表

你认为软件公司应该强制开发人员遵守编码规范吗？

coding-styleconventions
19

如果你认为它不应该，那么请解释原因。

如果是，你认为指南应该有多深？例如，代码缩进是否应该包括在内？

28个回答
35

我认为一个团队（而不是一家公司）需要就合理一致的风格制定一套指南。这样更有利于维护。

多深？尽可能简单。它越短，越清晰，团队成员就越可能同意并遵守它。

1
你的回答完美地概括了我的经验。团队应该定义他们的标准，这样每个成员都可以参与其中（我们称之为“认同”）。我们的团队领袖很少对风格做出“独裁式”的决定，而是总是讨论直到达成共识。 - Torsten Marek
3
我不同意。除了员工外，软件公司最宝贵的资源就是代码。团队之间需要有标准化，否则每个团队会变得越来越孤立。当一个团队成员移动到另一个团队时会发生什么？新的“标准”出现了。 - Even Mien
1
我通过个人经验和与各种团队合作发现，最容易推广的风格是最简单的风格。也就是说，避免沉迷于奇特的格式、命名方案等——整个KISS哲学。对于我们这些不得不使用来自许多作者的代码的人来说，我们习惯了很多不同的风格……除了那些引入各种新约定和格式风格的非常奇特的风格。简化一下，这样我们所有人就更容易达成共识了。 - stinky472
8
您希望每个人都能以标准化的方式阅读和编写代码。您可以通过以下两种方式实现：
  1. 克隆一个开发者并确保他们都接受相同的培训。希望他们能够编写相同的代码库。
  2. 向现有开发者明确说明您所需的内容。缩进使用制表符或空格，大括号的位置，如何进行注释，版本控制提交指南等。
您留下的未定义部分越多，开发者之间风格冲突的可能性就越高。
哎呀，我的评论被删除了。提到克隆是荒谬的。我的评论加剧了这一点。如果它被删除了，那么帖子也应该被删除，或者至少进行编辑。哇，这就是所谓的控制。 - mattlant
2
mattlant: 赞同。如果你在这个网站上做任何负面的事情（投票否决、删除评论、关闭帖子等），你一定要留下一个该死的评论解释为什么！你的评论很有趣，没有造成任何伤害。 - Oli
7
公司应该制定一些规范来指导开发。关于使用哪种规范以及规范的深度，应该由公司的开发者社区共同决定。
我肯定会制定一些关于大括号、缩进、命名等方面的指导原则...你要为代码的可读性和可维护性而编写代码。永远假设有其他人会阅读你的代码。有一些工具可以自动格式化你的代码，你可以强制要求每个人都使用这些工具。
如果你是在 .Net 平台上开发，请查看 StyleCop、FxCop 和 ReSharper。
1
我同意。工具会使遵守标准和检查合规性变得更容易。而且，与工具争辩起来也更困难 ;) - Patrick Cuff
7
你认为软件公司应该强制开发人员遵循编码风格吗？
不应该采取自上而下的方式。软件公司中的开发人员应该就通用的编码风格达成一致。
如果是的话，你认为指南应该有多深？
它们只应该描述与众所周知的惯例不同之处，尽可能减少偏差。这对于像Python或Java这样的语言很容易，对于C/C++来说有些模糊，而对于Perl和Ruby几乎是不可能的。
例如，代码缩进是否应包括在内？
是的，这使得代码更易读。在空格和制表符方面保持缩进一致（如果您选择使用空格，则保持空格字符的数量一致）。此外，请就长行达成一致的边距（例如76个字符或120个字符）。
5

是的，但要在合理范围内。

所有现代IDE都提供一键式代码美化功能，因此，在我看来，“缩进”点相当无关紧要。

更重要的是建立最佳实践：例如，尽可能少地使用“out”或“ref”参数...在这个例子中，你有两个优势：提高可读性并且还可以修复很多错误（很多out参数是一种代码味道，应该进行重构）。

超出这个范围，在我诚实的意见中，有点“过度追求完美”，对开发人员来说也是不必要的烦恼。

Hamish Smith提出了一个好观点：

风格与最佳实践是截然不同的。遗憾的是，“编码标准”往往将两者混为一谈。如果人们能够将样式部分最小化，并集中精力于最佳实践，那可能会增加更多价值。

2
风格与最佳实践非常不同。可惜的是，“编码标准”往往将两者混为一谈。如果人们能够将风格部分降至最低，并专注于最佳实践，那可能会增加更多价值。 - Hamish Smith
4

我认为作为一般规则，开发团队不应该有必须遵循的样式指南。当然有例外情况，例如在#include语句中使用<>与""的区别，但这些例外应该是出于必要。

我听到最常见的解释样式指南必要性的理由是，使用相同样式编写的代码比使用各种不同样式编写的代码更容易维护。我不认同这个观点。一个专业的程序员不会被这样的代码卡住：

for( int n = 0; n < 42; ++42 ) {
 // blah
}

......当他们习惯于看到这个时：

for(int n = 0; n < 42; ++42 )
{
 // blah
}

此外，我发现在有些情况下，如果你能通过识别代码作者的风格来识别原始代码的程序员，实际上更容易维护代码。请在10分钟内询问他们为什么以这种复杂的方式实现小装置，而不是花费大部分时间来找出他们出乎意料的技术原因。确实，程序员应该注释代码以解释他们的推理，但在现实世界中，程序员经常不这样做。
最后，如果Joe需要退格并移动花括号，以便Bill可以花费3秒钟查看代码，那么让Bill做一些对他不自然的事情真的节省了时间吗？
3

我认为拥有一致的代码库非常重要。它可以增加代码的可维护性。如果每个人都期望相同类型的代码，他们可以轻松地阅读和理解它。

此外，由于今天的IDE和其自动格式化功能，这并不是什么麻烦。

P.S：我有一个让人烦恼的习惯，就是把我的大括号放在下一行 :). 没有其他人似乎喜欢它

我也是，当if（条件）{...}中断时，如果它在下一行并正确缩进，检查正确的大括号就容易多了。 - UnkwnTech
我也是！我认为它能够大大地简化调试。当你时间紧迫，需要尽快修复错误时，这就更加重要了。我没有时间与语法斗争！ - Hector Sosa Jr
2
我认为程序员应该能够适应其他程序员的编程风格。如果新程序员无法适应，通常意味着新程序员过于固执，不愿使用公司的编程风格。如果我们都能按照一些基本准则编写代码，那将使调试和维护更加容易，尽管这只有在标准制定得很好且不太严格时才是真的。虽然我不完全同意其中的所有内容，但这本书提供了一个优秀的标准起点。
2
最好的解决方案是让集成开发环境将这样的格式视为元数据。例如，大括号的位置（当前行或下一行）、缩进和运算符周围的空格应该是可配置的，而不必更改源文件。
1
在我看来，标准和风格指南非常必要。因为当你的代码库增长时，你会希望它保持一致性。
顺便说一下，这就是为什么我喜欢Python的原因；因为它已经对如何构建应用程序等方面强加了很多规则。与Perl、Ruby或其他语言相比，你有极大的自由度（但在这种情况下并不好）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接