使用Stored Proc易于维护和较少的部署与使用ORM是面向对象的方式，因此它是好的

我在很多项目中都听到过这种说法，当这种说法出现时，总是很难解决。

Variable_Names_With_Bloody_Underscores

或者更糟

CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES

应该在全球范围内清除……与偏见!CamelCapsAreJustFine。 (全局常数不承受)

GOTO语句仅供11岁以下的开发人员使用

任何不支持指针的语言都名不副实

.Net = .Bloat 微软网站开发的最佳范例(无表情web 2) 是缓慢膨胀的最好的例子cr@pw@re曾经写过。 (可以试试Web Studio)

回应: 好的，让我来谈谈下划线的问题。从你提供的C链接:

-全局常量应该全部大写，用“_”分隔符。 我实际上同意这一点，因为这太明显了

-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。

我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。

C函数名 在c++项目中应该有很少的C函数。 对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。

的理由

* It makes C functions very different from any C++ related names. 

例子

int some_bloody_function () ｛ ｝

这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。

C被采纳为事实上的标准，不是因为它友好，而是因为它无处不在。我可以用一种语法友好的高级语言用20行代码编写100行C代码。

这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。

我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!

垃圾收集被高估了

许多人认为在Java中引入垃圾收集是与c++相比最大的改进之一。我认为最好的介绍是非常小的，编写良好的c++代码在适当的地方做了所有的内存管理(使用像RAII这样的技术)，所以不需要垃圾收集器。

生成的文档几乎总是毫无价值的。

或者，作为一个推论:您的API需要为维护者和用户提供单独的文档集。

实际上有两类人需要了解您的API:维护者，他们必须了解您的实现的细节，以便有效地完成工作;用户，他们需要高级的概述、示例和关于他们所访问的每个方法的效果的详细细节。

我从未遇到过在这两个方面都成功的生成文档。通常，当程序员为工具编写注释以提取和生成文档时，他们的目标是介于两者之间的某个地方——刚刚足够的实现细节让用户感到厌烦和困惑，但不足以显著帮助维护者，并且没有足够的概述对用户有任何真正的帮助。

As a maintainer, I'd always rather have clean, clear comments, unmuddled by whatever strange markup your auto-doc tool requires, that tell me why you wrote that weird switch statement the way you did, or what bug this seemingly-redundant parameter check fixes, or whatever else I need to know to actually keep the code clean and bug-free as I work on it. I want this information right there in the code, adjacent to the code it's about, so I don't have to hunt down your website to find it in a state that lends itself to being read.

As a user, I'd always rather have a thorough, well-organized document (a set of web pages would be ideal, but I'd settle for a well-structured text file, too) telling me how your API is architectured, what methods do what, and how I can accomplish what I want to use your API to do. I don't want to see internally what classes you wrote to allow me to do work, or files they're in for that matter. And I certainly don't want to have to download your source so I can figure out exactly what's going on behind the curtain. If your documentation were good enough, I wouldn't have to.

无论如何，这就是我的看法。

使用设计模式和文档

在web开发中，这些东西有什么用，从来没有觉得有什么用

观点:大多数代码都很糟糕，因为这是程序员想要的。

间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。

If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.

复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)

但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。

我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?

保罗。