问题标签 [coding-style]

为什么在这个千年里 Python PEP-8应该指定最大行长度为 79 个字符？

几乎所有的代码编辑器都可以处理更长的行。如何包装应该是内容消费者的选择，而不是内容创建者的责任。

在这个时代坚持 79 个字符是否有任何（合法的）充分理由？

我坚信使用单元测试作为构建大型多平台应用程序的一部分。我们目前正计划在一个单独的项目中进行单元测试。这有利于保持我们的代码库干净。但是，我认为这会将测试代码与单元的实现分开。您如何看待这种方法，是否有任何工具，如用于 c++ 应用程序的 JUnit？

我不喜欢人们使用 h3 而不是 h1，或者仅仅因为它的外观而跳过一个级别。恕我直言，标题表示文档结构，而不是布局。布局只是一个副作用，可以通过主题进行自定义。

“错误”的标题级别也使得生成正确的目录和/或导出到其他格式变得更加困难。

在进行 wiki 园艺时，是否可以完全重组其他人的页面以使用适当的嵌套标题级别？

看起来很容易找到这样的 Java 工具（Checkstyle，JCSC），但我似乎找不到 C/C++ 的工具。我不是在寻找类似 lint 的静态代码分析器，我只想检查变量命名、大写、间距、标识、括号放置等编码标准。

我这里有 300 行长的 NAnt 文件，非常混乱。我想知道是否有编写 NAnt 脚本的任何样式指南，以及这样做的最佳实践是什么。

有小费吗？

有人告诉我他们团队中的 C++ 风格差异。我对这个主题有自己的看法，但我会对每个人的利弊感兴趣。

所以，如果你有一个类属性，你想通过两个 getter 公开，一个是读/写，另一个是只读的（即没有 set 方法）。至少有两种方法：

每种方法的优缺点是什么？

我对 C++ 技术/语义原因更感兴趣，但也欢迎风格原因。

请注意，它MethodB有一个主要的技术缺陷（提示：在通用代码中）。

我在使用 Eclipse 和 java 时有点被宠坏了。我开始在 linux 环境中使用 vim 进行 C 编码，有没有办法让 vim 自动为块做适当的间距？

因此，在键入 { 后，下一行将缩进 2 个空格，并且该行上的 return 将使其保持相同的缩进，而 } 将移回 2 个空格？

I recently discovered that our company has a set of coding guidelines (hidden away in a document management system where no one can find it). It generally seems pretty sensible, and keeps away from the usual religious wars about where to put '{'s and whether to use hard tabs. However, it does suggest that "lines SHOULD NOT contain embedded multiple spaces". By which it means don't do this sort of thing:

Or this:

Or this:

The justification for this is that changes to one line often require every line to be edited. That makes it more effort to change, and harder to understand diffs.

I'm torn. On the one hand, lining up like this can make repetitive code much easier to read. On the other hand, it does make diffs harder to read.

What's your view on this?

我正在组建一个维护团队，并希望引入 FxCop 和 StyleCop 等工具来帮助改进代码并向开发人员介绍更好的编程技术和标准。由于我们正在维护代码而不是进行重大改进，因此在进行更改时我们可能一次只处理几个方法/例程。

是否可以将 FxCop/StyleCop 定位到 Visual Studio 中的特定代码区域，以避免在分析整个类或项目时被引发的所有问题所淹没？如果有可能，你会怎么做？

谢谢，马特

如何将样式应用于 CheckBoxList ListItems。与其他控件不同，例如可以指定的 Repeater，您<ItemStyle>似乎无法为每个单独的控件指定样式。

有什么解决办法吗？