我不止一次使用过这个方法，当我对一个数学公式做了一些不明显的简化时，我不想记录:

//this formula is right, work out the math yourself if you don't believe me

我个人最喜欢的是打油诗形式的文档:

        Subclassing made Zope and TR
        much harder to work with by far.
            So before you inherit,
            be sure to declare it
        Adapter, not PyObject*

这可能会破坏这个笑话，但由于它有点晦涩，我将解释:

这里的TR指的是“扭曲的现实”。Zope 2和最初的扭曲。Reality包大量而不幸地使用了多重继承，这可能会使您在看到方法调用时难以理解发生了什么。Zope 3，扭曲自己，扭曲。现实的后继者(包括最近的假想)通常更倾向于组件组合。

这不是严格意义上的评论，但是…

那是20世纪90年代中期，我正在进行一次大的迁移:小软件供应商，大客户，压力很大。我们有很多转移门柱的东西;这个项目很难控制。我是关键的开发人员，但对系统还不熟悉，而另一个开发人员是供应商的所有者/创始人。

在几个月没有按时完成任务，也没有让客户满意之后，公司的所有者/创始人找来了另一名远程工作的开发人员。(我可以大胆地说，新开发人员的技能和经验都不如我。)

好吧，这个新人对我已经做过的代码做了一些更改，然后一两个月后我又回到了代码的同一区域，其中有一些我以前没有见过的变量。他的名字叫StupidMark。

伙计，这是不对的。我的意思是，有团队合作方面的考虑，但是:在这个环境中，变量名可能会出现在运行时错误消息中。我只是说说而已。

在我看来，那个新人的代码并没有让我们更接近可交付的产品，这让侮辱变得更伤人了。

//Abandon all hope ye who enter beyond this point

来自usenet的经典:

Teradyne硬件建模器代码的深层是一个例程 一大堆十六进制数字到SYS$QIO调用中。唯一的评论是 “这里发生了奇怪的魔法”。

  mov si, pCard      ; captain?