如果您认为不应该，请解释原因。
如果是，您认为指南应该有多深？例如，应该包括代码的缩进吗？
friol
问问题
2023 次
28 回答
34
我认为一个团队（而不是一个公司）需要就一套合理一致的风格达成一致。它使维护更加简单。
有多深？尽可能肤浅，你可以同意。它越短越清晰，就越有可能所有团队成员都同意并遵守它。
于 2008-09-28T09:10:45.833 回答
8
您希望每个人都以标准方式阅读和编写代码。有两种方法可以实现这一目标：
- 多次克隆一个开发人员，并确保他们都经过相同的培训。希望他们都应该能够编写相同的代码库。
- 向您现有的开发人员明确说明您的需求。用于缩进的制表符或空格。大括号所在的位置。怎么评论。版本控制提交指南。
您留下的未定义越多，开发人员在风格上发生冲突的可能性就越高。
于 2008-09-28T09:09:13.200 回答
7
公司应该强制要求遵循某种风格。那是什么风格以及指南的深度应该由公司的开发人员社区共同决定。
我肯定会制定关于大括号、缩进、命名等的指导方针……你编写代码是为了可读性和可维护性。始终假设其他人会阅读您的代码。有一些工具可以自动神奇地格式化你的代码，你可以强制每个人都使用这个工具。
如果您在 .Net 上，请查看 stylecop、fxcop 和 Resharper
于 2008-09-28T09:10:50.513 回答
7
你认为软件公司应该强加开发人员编码风格吗？
不是自上而下的方式。软件公司的开发人员应该就通用的编码风格达成一致。
如果是，您认为指南应该有多深？
他们应该只描述与众所周知的约定的差异，尽量保持偏差最小。这对于 Python 或 Java 这样的语言来说很容易，对于 C/C++ 来说有些模糊，对于 Perl 和 Ruby 几乎是不可能的。
例如，应该包括代码的缩进吗？
是的，它使代码更具可读性。在空格与制表符和（如果您选择空格）空格字符数方面保持缩进一致。此外，就长行的边距（例如 76 个字符或 120 个字符）达成一致。
于 2008-09-28T09:47:54.497 回答
5
是的，但在合理范围内。
所有现代 IDE 都提供漂亮的一键式代码，因此在我看来，“缩进”点是完全无关紧要的。
更重要的是建立最佳实践：例如，尽可能少地使用“out”或“ref”参数......在这个例子中，您有两个优点：提高可读性并修复了很多错误（很多out 参数是代码异味，可能应该重构）。
超出这个范围，老实说，对于开发人员来说，有点“肛门”并且不必要地烦人。
哈米什·史密斯的好观点：
风格与最佳实践完全不同。遗憾的是，“编码标准”倾向于将两者结合在一起。如果人们可以将样式部分保持在最低限度并专注于可能会增加更多价值的最佳实践。
于 2008-09-28T09:07:35.200 回答
4
我不认为开发团队应该有他们必须遵循的风格指南作为一般规则。有例外，例如在#include statements 中使用 <> 与 ""，但这些例外应该来自必要性。
我听到人们用来解释为什么需要样式指南的最常见原因是，以通用样式编写的代码更容易维护以单独样式编写的代码。我不同意。当一个专业的程序员看到这个时，他们不会陷入困境：
for( int n = 0; n < 42; ++42 ) {
// blah
}
...当他们习惯于看到这个时：
for(int n = 0; n < 42; ++42 )
{
// blah
}
此外，我发现在某些情况下，如果您可以通过简单地识别他们的风格来识别编写原始代码的程序员，那么在某些情况下维护代码实际上会更容易。去问问他们为什么他们在 10 分钟内以如此复杂的方式实现了这个小发明，而不是花一天的大部分时间来弄清楚他们为什么做了一些意想不到的事情的技术原因。诚然，程序员应该对代码进行注释以解释他们的推理，但在现实世界中，程序员通常不会这样做。
最后，如果 Joe 需要 10 分钟退格并移动他的花括号，以便 Bill 可以少花 3 秒查看代码，是否真的节省了让 Bill 做一些他不自然的事情的时间？
于 2008-10-08T21:55:45.360 回答
3
我相信拥有一致的代码库很重要。它增加了你的代码的可维护性。如果每个人都期望相同类型的代码，他们可以很容易地阅读和理解它。
此外，鉴于当今的 IDE 及其自动格式化功能，这并不麻烦。
PS：我有个讨厌的习惯，就是把牙套放在下一行:)。似乎没有人喜欢它
于 2008-09-28T09:01:53.607 回答
2
我认为程序员应该能够适应其他程序员的风格。如果一个新程序员无法适应，那通常意味着新程序员太固执，无法使用公司的风格。如果我们都能做自己的事就好了；但是，如果我们都按照一些粗俗的准则进行编码，它会使调试和维护变得更容易。仅当标准经过深思熟虑且不太严格时，这才是正确的。
于 2008-09-28T09:06:48.387 回答
2
最好的解决方案是 IDE 将这种格式视为元数据。例如，左大括号位置（当前行或下一行）、缩进和运算符周围的空格应该是可配置的，而无需更改源文件。
于 2008-09-28T10:08:48.020 回答
1
在我看来，我认为标准和风格指南是非常必要的。因为当你的代码库增长时，你会希望它保持一致。
作为旁注，这就是我喜欢 Python 的原因；因为它已经对如何构建应用程序等施加了很多规则。将其与 Perl、Ruby 或任何您拥有极大自由的地方（在这种情况下并不是那么好）进行比较。
于 2008-09-28T09:04:00.810 回答
1
标准有很多充分的理由来定义应用程序的开发方式和代码的外观。例如，当每个人都使用相同的标准时，可以使用自动样式检查器作为项目 CI 的一部分。使用相同的标准可以提高代码的可读性，并有助于减少团队成员之间以不同方式重构相同代码的紧张关系。所以：
- 特定团队开发的所有代码都应遵循完全相同的标准。
- 为特定项目开发的所有代码都应遵循完全相同的标准。
- 属于同一公司的团队最好使用相同的标准。
在外包公司中，如果客户想要执行他们自己的标准，那么为客户工作的团队可以例外。在这种情况下，团队采用客户的标准，这可能与他们公司使用的标准不兼容。
于 2008-09-28T09:14:08.180 回答
1
就像其他人提到的那样，我认为这需要由工程或团队来决定——公司（即业务部门）不应该参与那种决策。
但我要补充的另一件事是，任何实施的规则都应该由工具而不是人来执行。最坏的情况，IMO，是一些过分热心的语法势利小人（是的，我们存在；我知道是因为我们可以闻到我们自己的味道）写了一些文档，概述了一组绝对没有人真正阅读或遵循的编码指南。随着时间的推移，它们会变得过时，随着新人加入团队和老年人离开，它们就会变得陈旧。
然后，一些冲突出现了，某人被置于不得不就编码风格与其他人对抗的尴尬境地——这种对抗应该由工具而不是人来完成。简而言之，在我看来，这种强制执行方法是最不可取的，因为它太容易被忽视，而且只会乞求程序员争论愚蠢的事情。
一个更好的选择（同样，IMO）是在编译时抛出警告（或类似的东西），只要您的构建环境支持这一点。在 VS.NET 中配置它并不难，但我不知道其他具有类似功能的开发环境。
于 2008-10-08T15:55:11.690 回答
1
风格指南非常重要，无论是用于设计还是开发，因为它们加快了协作工作（甚至是单独工作，按顺序工作，就像拾取旧项目的碎片时）的人们的沟通和绩效。公司内部没有约定俗成的系统只是要求人们尽可能地低效。大多数项目都需要协作，即使是那些不需要协作的项目也容易受到我们锻炼编程能力和保持最新的自然愿望的影响。我们的学习欲望阻碍了我们的一致性——这本身就是一件好事，但会让新员工疯狂地尝试学习他们正在学习的系统。
就像任何其他善而不恶的系统一样，指南的真正力量掌握在其人民的手中。开发人员自己将确定基本和有用的部分是什么，然后有希望地使用它们。
就像法律一样。或者英语。
风格指南应该尽可能深入——如果它出现在头脑风暴会议中，它应该被包括在内。您对问题的措辞很奇怪，因为归根结底，没有办法“强加”样式指南，因为它只是一个指南。
RTFM，然后收集好东西并继续使用它。
于 2008-10-08T16:42:43.667 回答
0
是的，我认为公司应该这样做。开发人员可能需要习惯编码风格，但在我看来，一个好的程序员应该能够使用任何编码风格。正如 Midhat 所说：拥有一致的代码库很重要。
我认为这对于开源项目也很重要，没有主管告诉你如何编写代码，但许多语言都有关于代码的命名和组织方式的规范。在将开源组件集成到您的项目中时，这很有帮助。
于 2008-09-28T09:12:36.780 回答
0
当然，指导方针是好的，除非它是使用不当的匈牙利符号（哈！），否则它可能会提高一致性并使阅读其他人的代码更容易。不过，这些指导方针应该只是指导方针，而不是对程序员强制执行的严格规则。你可以告诉我把大括号放在哪里或者不使用像 temp 这样的名称，但你不能做的是强迫我在数组括号中的索引值周围有空格（他们尝试过一次......）
于 2008-09-28T09:12:57.950 回答
0
是的。
编码标准是确保特定组织内的代码遵循最小意外原则的常用方法：从变量命名到缩进到大括号使用的标准一致性。
拥有自己风格和自己标准的编码人员只会产生不一致、混乱和令人沮丧的代码库，尤其是在大型项目中。
于 2008-09-28T09:14:47.180 回答
0
这些是我曾经工作过的公司的编码标准。它们定义明确，虽然我花了一段时间才习惯它们，但这意味着我们所有人都可以阅读代码，并且始终保持统一。
我确实认为编码标准在公司内部很重要，如果没有设置，开发人员之间就会发生冲突，并且会出现可读性问题。
使代码始终保持一致，为最终用户提供了更好的代码（因此它看起来好像是由一个人编写的——从最终用户的角度来看，它应该——那个人是“公司”，它还有助于团队内的可读性...
于 2008-09-28T09:17:59.187 回答
0
共同的编码风格促进了一致性，并使不同的人能够轻松地理解、维护和扩展整个代码库，而不仅仅是他们自己的代码。它还使新人更容易更快地学习代码。因此，任何团队都应该对如何编写代码有一个指导方针。
重要的指导方针包括（不分先后）：
- 空格和缩进
- 标准注释——文件、类或方法头
- 命名约定——类、接口、变量、命名空间、文件
- 代码注释
- 项目组织 - 文件夹结构、二进制文件
- 标准库——使用什么模板、泛型、容器等
- 错误处理 - 异常、hresults、错误代码
- 线程和同步
另外，要警惕那些不能或不会适应团队风格的程序员，无论他们多么聪明。如果他们不遵守其中一项球队规则，他们可能也不会遵守其他球队规则。
于 2008-09-28T09:31:21.277 回答
0
我同意一致性是关键。您不能依靠 IDE 漂亮打印来挽救局面，因为您的一些开发人员可能不喜欢使用 IDE，并且因为当您浏览包含数千个源文件的代码库时，漂亮根本不可行当你开始处理它们时打印所有文件，然后执行回滚，这样你的 VCS 就不会尝试提交所有更改（用不必要的更新阻塞存储库，给每个人带来负担）。
我建议至少标准化以下内容（按重要性降序排列）：
- 空白（如果您选择符合某些共享工具的自动漂亮打印的样式，这是最简单的）
- 命名（文件和文件夹、类、函数、变量……）
- 评论（使用允许自动生成文档的格式）
于 2008-09-28T10:06:28.540 回答
0
我的意见：
- 一些基本规则很好，因为它可以帮助每个人阅读和维护代码
- 太多的规则是不好的，因为它会阻止开发人员以更清晰的代码布局方式进行创新
- 单个样式可用于确定代码文件的历史。可以使用差异/责备工具，但提示仍然有用
于 2008-09-28T13:45:37.733 回答
0
现代 IDE 允许您定义格式模板。如果有企业标准，那么开发一个配置文件，定义您关心的所有格式化值，并确保每个人在签入代码之前都运行格式化程序。如果您想更加严格，您可以为您的版本控制系统添加一个提交挂钩，以便在代码被接受之前缩进代码。
于 2008-09-28T15:14:34.930 回答
0
是的，就使用通用命名标准以及类和代码隐藏文件的通用布局而言。其他一切都是开放的。
于 2008-09-28T17:20:57.807 回答
0
每个公司都应该。一致的编码风格可确保整个团队的代码库具有更高的可读性和可维护性。
我工作的商店没有统一的编码标准，我可以说我们（作为一个团队）深受其害。当个人没有意愿时（比如我的一些同事），团队负责人必须用拳头敲桌子并强加某种形式的标准化编码准则。
于 2008-09-28T17:28:38.493 回答
0
任何语言都有社区使用的通用标准。您应该尽可能地遵循这些，以便您的代码可以由习惯该语言的其他人维护，但没有必要对它进行独裁。
制定官方标准是错误的，因为公司编码标准通常过于死板，无法与使用该语言的一般社区交流。
如果您对某个团队成员的编码风格有问题，那么团队温和地建议这在代码审查中不是一个好主意是一件好事。
于 2008-09-28T18:01:05.030 回答
0
编码标准：是。由于此线程中已涵盖的原因。
造型标准：NO。你的可读性，是我眼花缭乱的垃圾，反之亦然。好的注释和代码分解有更大的好处。还有gnu缩进。
于 2008-10-01T05:26:27.533 回答
0
我喜欢 Ilya 的回答，因为它结合了可读性的重要性，以及使用持续集成作为执行机制。Hibri 提到了 FxCop，我认为在构建过程中将其用作确定构建是否通过或失败的标准之一将比仅仅记录标准更加灵活和有效。
于 2008-10-08T15:44:34.847 回答
0
我完全同意应该应用编码标准，并且应该几乎总是在团队级别。但是有几个例外。
如果团队正在编写供其他团队使用的代码（这里我的意思是其他团队将不得不查看源代码，而不仅仅是将其用作库），那么在所有团队中制定通用标准是有好处的使用它。同样，如果公司的政策是经常将程序员从一个团队转移到另一个团队，或者处于一个团队经常想要重用另一个团队的代码的位置，那么最好在整个公司范围内实施标准。
于 2008-10-08T15:53:53.220 回答
0
有两种类型的约定。
A 类约定：“请做这些，这样更好”
和B型：“请在马路的右侧行驶”，而在另一侧行驶也可以，只要每个人都按照相同的方式行驶即可。
没有单独的团队这样的事情。一家好公司的所有代码都以某种方式连接在一起，并且风格应该是一致的。习惯一种新风格比适应二十种不同的风格更容易。
此外，新开发人员应该能够尊重现有代码库的实践并遵循它们。
于 2009-12-29T13:35:27.157 回答