您是否认为软件公司应该将开发人员强加给编码风格？

Question

如果您认为不应该,请解释原因.

如果是,您认为指南有多深？例如,应包括代码缩进？

Answer 1

我认为团队(而不是公司)需要就合理一致的风格达成一套指导方针.它使维护更加简单.

有多深？你可以同意的浅薄.它越短越清晰,所有团队成员都越有可能同意并遵守它.

Answer 2

您希望每个人都以标准方式阅读和编写代码.有两种方法可以实现这一目标:

1. 多次克隆一位开发人员并确保他们都经过相同的培训.希望他们都应该能够编写相同的代码库.
2. 为您现有的开发人员提供您所需要的明确指示.用于缩进的制表符或空格.坐在哪里.如何评论.版本控制提交指南.

你保留的未定义越多,其中一个开发人员会在风格上发生冲突的概率就越高.

Answer 3

公司应该强调应该遵循一些风格.什么样的风格和指南的深度应该由公司的开发者社区共同决定.

我肯定会在括号,缩进,命名等方面制定指导方针......您编写了可读性和可维护性的代码.总是假设其他人要读你的代码.有些工具可以自动格式化您的代码,您可以强制要求每个人都使用该工具.

如果你在.Net上看看stylecop,fxcop和Resharper

Answer 4

您是否认为软件公司应该将开发人员强加给编码风格？

不是自上而下的方式.软件公司的开发人员应该就共同的编码风格达成一致.

如果是,您认为指南有多深？

它们应该只描述与众所周知的惯例的差异,试图将偏差保持在最小.这对于像Python或Java这样的语言来说很容易,对于C/C++来说有点模糊,而对于Perl和Ruby来说几乎是不可能的.

例如,应包括代码缩进？

是的,它使代码更具可读性.保持缩进在空格与制表符和(如果选择空格)空格字符数方面一致.此外,同意长线的保证金(例如76个字符或120个字符).

Answer 5

是的,但在合理范围内.

所有现代IDE都提供一键式代码精美打印,因此在我看来,"缩进"点是无关紧要的.

更重要的是建立最佳实践:例如,尽可能少地使用"out"或"ref"参数......在这个例子中,你有两个优点:提高可读性并修复了很多错误(很多) out参数是代码气味,应该可以重构.

超出这个范围,在我的诚实意见中,有点"肛门"并且不必要地为开发者烦恼.

哈米什史密斯的好点:

风格与最佳实践完全不同.令人遗憾的是,"编码标准"倾向于将两者结合在一起.如果人们能够将风格部分保持在最低限度并专注于可能会增加更多价值的最佳实践.