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()函数/变量名还没有让我失望!

开发团队应该更多地按照技术/架构层而不是业务功能来划分。

我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储procs，匹配数据访问代码，实现业务逻辑和web服务方法，以及web页面接口。

And guess what? Everybody has their own way to doing things! Everyone struggles to learn the ASP.NET AJAX and Telerik or Infragistic suites, Enterprise Library or other productivity and data layer and persistence frameworks, Aspect-oriented frameworks, logging and caching application blocks, DB2 or Oracle percularities. And guess what? Everybody takes heck of a long time to learn how to do things the proper way! Meaning, lots of mistakes in the meantime and plenty of resulting defects and performance bottlenecks! And heck of a longer time to fix them! Across each and every layer! Everybody has a hand in every Visual Studio project. Nobody is specialised to handle and optmise one problem/technology domain. Too many chefs spoil the soup. All the chefs result in some radioactive goo.

Developers may have cross-layer/domain responsibilities, but they should not pretend that they can be masters of all disciplines, and should be limited to only a few. In my experience, when a project is not a small one and utilises lots of technologies, covering more business functions in a single layer is more productive (as well as encouraging more test code test that layer) than covering less business functions spanning the entire architectural stack (which motivates developers to test only via their UI and not test code).

一个优秀的开发人员需要知道的不仅仅是如何编码

在我的工作场所，我一直试图引入更多的敏捷/XP开发习惯。持续设计是迄今为止我觉得阻力最大的一个。也许我不应该说“让我们召集所有的架构团队并射杀他们”……；）

SESE (Single Entry Single Exit)不是法律

例子:

public int foo() {
   if( someCondition ) {
      return 0;
   }

   return -1;
}

vs:

public int foo() {
   int returnValue = -1;

   if( someCondition ) {
      returnValue = 0;
   }

   return returnValue;
}

我和我的团队发现，在很多情况下，一直遵守这一点实际上会适得其反。

好吧，我说过我会更详细地阐述我的“密封类”观点。我想有一种方法可以展示我感兴趣的答案，那就是给我自己一个答案:)

意见:在c#中，默认情况下类应该是密封的

推理:

There's no doubt that inheritance is powerful. However, it has to be somewhat guided. If someone derives from a base class in a way which is completely unexpected, this can break the assumptions in the base implementation. Consider two methods in the base class, where one calls another - if these methods are both virtual, then that implementation detail has to be documented, otherwise someone could quite reasonably override the second method and expect a call to the first one to work. And of course, as soon as the implementation is documented, it can't be changed... so you lose flexibility.

C# took a step in the right direction (relative to Java) by making methods sealed by default. However, I believe a further step - making classes sealed by default - would have been even better. In particular, it's easy to override methods (or not explicitly seal existing virtual methods which you don't override) so that you end up with unexpected behaviour. This wouldn't actually stop you from doing anything you can currently do - it's just changing a default, not changing the available options. It would be a "safer" default though, just like the default access in C# is always "the most private visibility available at that point."

通过让人们明确表示他们希望人们能够从他们的类中派生，我们将鼓励他们更多地思考这个问题。这也可以帮助我解决我的懒惰问题——虽然我知道我应该密封几乎所有的类，但我很少真的记得这样做:(

对方观点:

我可以看到这样一种说法:可以相对安全地派生没有虚方法的类，而不需要额外的灵活性和通常需要的文档。目前我不确定如何应对这个问题，只能说我相信意外打开类的危害比意外密封类的危害更大。