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


当前回答

对于我编写的memcache包装器/处理程序接口模式类,我实现了以下方法。

/**
*  Do not use, ever - left in place for testing purposes
*/
function  I_David_WillHuntYouDownAndHurtYou_Badly_IfIFindThisUsedAnyWhereInTheAppLibrary(){
...
}

这基本上是一个超级核函数,它告诉所有单独的memcache服务完全刷新自己,并从我用于键的单个名称空间计数器(例如{_counter_key value}_)重新开始。{_counter_key value})

Another minor novella I wrote was for an automated downloader for a data vendor, detailing how much I hated this vendor and went to great lengths of postulating that their infrastructure's batch system was run by a gerbil, running on a wheel and after so many revolutions of the wheel the next queued task would be started. It was written over the course of 6 months of adding additional exception handling, estoric checks like ( if we got 768 Bytes of \s characters, that means the query to their DB timed out and the spaces are the result of empty failure print statements.

其他回答

/*
* Wirzenius wrote this portably, Torvalds fucked it up :-)
*/

在20世纪80年代早期的某个时候,我们在PL/I中为公用事业编写财务建模代码。接到一个客户的电话,说代码在评论之后就爆炸了

/* Honest this works */

这家伙用了我们的标准金融方程花了大约15页的代数把一堆代码组合成一个方程。在三里岛事件后,当公用事业公司不得不以巨大的代价注销他们的核电站时,这个方程失败了,因为FIXED BIN 15(整数)溢出,如果代数没有发生,就不会发生这种溢出。

Catch (Exception e) {
 //who cares?
} 
// Oh crap, i think i'm gonna yack

随后不久又有:

// TODO: end this lunacy

几年前,我在一个没有单元测试可言的大型代码库中工作。

代码中隐藏了一个执行一些日历计算的方法。它有点坏了,由于一些不幸的情况,不得不以一种非常笨拙的方式处理夏令时。

我们不得不修了几次,每一次,我们都会在几个月后发现一些东西坏了。

在花了一整天的时间修复和分析之后,我把代码放到了源代码控制中,并附上了这样的评论:

// this code was written after a version trying to do {this} failed because of {reason},
// previously we were doing {this} which failed because of {reason}. This is 
// now written {this} way so that {lots of reasons here}. If you want to touch
// this code, please make sure that it produces the right answers when tested with:
//
// {some sort of unit test}

最终,我的团队被外包了。有时我想知道这段代码发生了什么:)