复制/粘贴不是反模式，事实上它有助于避免产生更多的错误

我的经验法则——只输入不能复制/粘贴的东西。如果创建类似的方法，类或文件-复制现有的并更改所需的内容。(我不是在谈论复制应该放在单个方法中的代码)。

我通常从不输入变量名——要么复制粘贴，要么使用IDE自动补全。如果需要一些DAO方法-复制类似的方法并更改所需的内容(即使将更改90%)。对某些人来说，这可能看起来是极度的懒惰或缺乏知识，但我几乎从来没有处理过由拼写错误引起的问题，而且它们通常很难捕捉(如果没有在编译级别检测到)。

每当我偏离我的复制粘贴规则，开始输入东西时，我总是拼写错误(这只是一个统计数据，没有人能立即写出完美的文本)，然后花更多的时间试图找出哪里。

低驼峰是愚蠢和没有语义的

使用lower camelCase使名称/标识符(从这里开始使用“name”)看起来像两个部分。然而，Upper CamelCase给出了清晰的指示，所有的单词都属于一起。

匈牙利符号是不同的…因为名称的第一部分是类型指示符，所以它与名称的其余部分具有单独的含义。

有些人可能会认为小写的驼峰大小写应该用于函数/过程，特别是在类内部。这在Java和面向对象的PHP中很流行。然而，没有理由这样做来表明它们是类方法，因为通过它们被访问的方式，很明显它们只是类方法。

一些代码示例:

# Java
myobj.objMethod() 
# doesn't the dot and parens indicate that objMethod is a method of myobj?

# PHP
$myobj->objMethod() 
# doesn't the pointer and parens indicate that objMethod is a method of myobj?

Upper CamelCase对于类名和其他静态名很有用。所有非静态内容都应该通过它们的访问方式来识别，而不是通过它们的名称格式(!)

这是我的同质代码示例，其中名称行为由其他事物表示，而不是它们的名称……(另外，我更喜欢用下划线来分隔名字中的单词)。

# Java
my_obj = new MyObj() # Clearly a class, since it's upper CamelCase
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # Clearly an attribute, since it's referenced

# PHP
$my_obj = new MyObj()
$my_obj->obj_method()
$my_obj->obj_var
MyObj::MyStaticMethod()

# Python
MyObj = MyClass # copies the reference of the class to a new name
my_obj = MyObj() # Clearly a class, being instantiated
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # clearly an attribute, since it's referenced
my_obj.obj_method # Also, an attribute, but holding the instance method.
my_method = myobj.obj_method # Instance method
my_method() # Same as myobj.obj_method()
MyClassMethod = MyObj.obj_method # Attribute holding the class method
MyClassMethod(myobj) # Same as myobj.obj_method()
MyClassMethod(MyObj) # Same as calling MyObj.obj_method() as a static classmethod

这就是我对camelCase完全客观的看法。

代码中的大多数注释实际上是一种有害的代码复制形式。

我们花了大部分时间维护别人(或者我们自己)写的代码，糟糕的、不正确的、过时的、误导性的注释肯定是代码中最令人讨厌的工件列表的顶部。

我想最终很多人会忘记它们，尤其是那些花盒子里的怪物。

最好集中精力使代码可读，必要时进行重构，并尽量减少习惯用法和奇怪之处。

另一方面，许多课程告诉我们注释几乎比代码本身更重要，这就导致了下面这一行添加了一个注释到invoiceTotal风格。

不要在数据库中使用stored proc。

它们最初的优点——安全性、抽象性、单一连接——都可以在集成了许多其他优点的orm的中间层中实现。

这无疑是有争议的。每次我提起这件事，人们就把我撕成碎片。

代码布局很重要

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

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

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

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

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

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

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

(编辑)

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

Web服务绝对很糟糕，也不是未来的发展方向。他们的效率低得可笑，而且他们不能保证订单交货。Web服务绝不应该在同时编写客户端和服务器的系统中使用。它们对于米老鼠混搭类型的应用程序非常有用。它们绝对不应该用于任何类型的面向连接的通信。

这种立场让我和同事们进行了一些非常热烈的讨论，因为web服务是一个非常热门的话题。任何强制使用web服务的项目都是注定要失败的，因为它显然已经从管理层那里得到了荒谬的要求。