有时候赶时髦是可以的

我厌倦了人们表现出“爷爷综合症”(“你们这些孩子和你们新奇的测试驱动开发。过去十年出现的每一项大技术都很糟糕。在我那个年代，我们写的是真正的代码!”你懂的)。

有时候，受欢迎的事物是有原因的。

Never make up your mind on an issue before thoroughly considering said issue. No programming standard EVER justifies approaching an issue in a poor manner. If the standard demands a class to be written, but after careful thought, you deem a static method to be more appropriate, always go with the static method. Your own discretion is always better than even the best forward thinking of whoever wrote the standard. Standards are great if you're working in a team, but rules are meant to be broken (in good taste, of course).

所有源代码和注释都应该用英文编写

用英语以外的语言编写源代码和/或注释会降低可重用性，如果你不理解它们所使用的语言，就更难调试。

SQL表、视图和列也是如此，特别是在使用缩写时。如果它们没有缩写，我可能能够在线翻译表/列名，但如果它们被缩写，我所能做的就是选择并尝试破译结果。

SQL可以而且应该做得更好。由于其原始规范有限，多年来各种厂商一直在向不同方向扩展该语言。为MS-SQL编写的SQL与为Oracle、IBM、MySQL、Sybase等编写的SQL不同。其他严肃的语言(以c++为例)都经过了仔细的标准化，因此在一个编译器下编写的c++通常可以在另一个编译器下编译而无需修改。为什么SQL不能被更好地设计和标准化呢?

HTML作为浏览器显示语言是一个严重的错误选择。我们花了数年时间通过CSS、XHTML、Javascript、Ajax、Flash等进行扩展，以制作一个可用的UI，但结果仍然不如你的基本厚客户端windows应用程序。此外，一个称职的web程序员现在需要了解三到四种语言才能制作一个像样的UI。

噢,是的。匈牙利符号令人厌恶。

QA应该比开发人员更了解代码(间接地)。QA通过发现开发人员不希望发生的事情而获得报酬，他们经常这样做。(顺便说一句，我是一名非常看重优秀QA人员的开发者。很少)。

代码布局很重要

也许双括号位置的细节应该保持纯粹的宗教争论-但这并不意味着所有的布局风格都是平等的，或者根本没有客观因素!

问题在于布局的超级规则，即:“保持一致”，尽管听起来不错，但被许多人用作拐杖，从不尝试看看他们的默认风格是否可以改进——而且，这甚至无关紧要。

几年前，我正在学习快速阅读技术，我学到的一些东西是关于眼睛如何在“固定”中获取信息，如何最优地扫描页面，以及潜意识中拾取上下文的作用，这让我思考如何将其应用到代码中——尤其是在编写代码时牢记它。

它使我形成了一种本质上倾向于柱状的样式，在可能的情况下对标识符进行逻辑分组和对齐(特别是我严格要求每个方法参数都在自己的行上)。然而，与一成不变的长柱结构相比，以块为单位改变结构实际上是有益的，这样你最终会得到眼睛可以在一个固定装置中接受的矩形岛屿——即使你没有有意识地阅读每个字符。

最终的结果是，一旦你习惯了它(通常需要1-3天)，它就会变得赏心悦目，更容易理解，对眼睛和大脑的负担也更少，因为它的布局方式更容易接受。

几乎无一例外，我邀请的每个尝试这种风格的人(包括我自己)一开始都说，“啊，我讨厌它!”，但过了一两天就说，“我喜欢它——我发现很难不回头用这种方式重写我所有的旧东西!”

我一直希望有时间做更多的对照实验，以收集足够的证据来写一篇论文，但一直忙于其他事情。然而，这似乎是一个向那些对有争议的技术感兴趣的人提及它的好机会:-)

(编辑)

我终于抽出时间把这件事写在博客上(在“意义”阶段停留了很多年之后):第一部分，第二部分，第三部分。