写得很好的Lisp是最容易阅读的语言之一，我喜欢它。但是写得不好的Lisp可能是比糟糕的Java更糟糕的噩梦，等等。

在这里，我们需要创建一个“组文件”，如果一个原始文件有3个变体，后缀为a, b和c。我一直试图追踪一个奇怪的错误，我们得到了不必要的组文件……

  (let ((varianta (format nil "~aa" problem))
        (variantb (format nil "~ab" problem))
        (variantc (format nil "~ac" problem)))
    ;;if the A and B variants exist, create a group file
    ;;(why not just check for a? I don't know, this just feels right)
    (when (and (probe-file varianta)
               (probe-file variantb))
      ...)))

Bug: 1, Gut: 0。

显然，写这篇文章的人没有想到，也许检查所有三种变体是一个好主意。当然，这是我在最初编写这段代码十年之后(它比第一个SVN日志更早)最终追踪到的错误。

我一直很喜欢Paul DiLascia在他的文件头中写的:

// If this code works, it was written by Paul DiLascia. If not, I don't know
// who wrote it

问:“你遇到过的源代码中最好的注释是什么?”

A:很简单——就是那个帮我解决了我当时遇到的任何问题的人，而且有很多这样的人!

其次是那些帮助指导新开发避免已知陷阱的方法。

//我知道这很让人困惑，所以让我解释给你听。

我在一个充满显式怪异类型转换的函数中见过这段代码:

// Since today's CPUs are really fast, this is dedicated to those who said:
// " You can't use Moore's Law as an excuse to write bad software. "

代码太可怕了:)

/**
 * Hexadecimal digit
 */
protected $version = -1;