我们都知道,注释我们的代码是编码风格的重要组成部分,它可以让下一个出现的人,甚至是我们自己在 6 个月左右的时间内都能理解我们的代码。
但是,有时评论并不能解决问题。我不是在谈论明显的笑话或发泄的挫败感,我说的是似乎试图解释的评论,但做得很糟糕,他们可能不在那里。太短、太神秘或完全错误的评论。
作为一个警示故事,您能否分享您所看到的确实很糟糕的东西,如果不是很明显,请显示它所指的代码并指出它有什么问题?那里应该放什么?
也可以看看:
我们都知道,注释我们的代码是编码风格的重要组成部分,它可以让下一个出现的人,甚至是我们自己在 6 个月左右的时间内都能理解我们的代码。
但是,有时评论并不能解决问题。我不是在谈论明显的笑话或发泄的挫败感,我说的是似乎试图解释的评论,但做得很糟糕,他们可能不在那里。太短、太神秘或完全错误的评论。
作为一个警示故事,您能否分享您所看到的确实很糟糕的东西,如果不是很明显,请显示它所指的代码并指出它有什么问题?那里应该放什么?
也可以看看:
只是典型的 Comp Sci 101 类型注释:
$i = 0; //set i to 0
$i++; //use sneaky trick to add 1 to i!
if ($i==$j) { // I made sure to use == rather than = here to avoid a bug
之类的东西。
未填充的 javadoc 样板注释特别无用。他们消耗了大量的屏幕空间,却没有提供任何有用的东西。最糟糕的是,在出现这样一条评论的地方,肯定有数百条评论在后面。
/**
* Method declaration
*
*
* @param table
* @param row
*
* @throws SQLException
*/
void addTransactionDelete(Table table, Object row[]) throws SQLException {
我发现自己以前写过这个小宝石:
//@TODO: Rewrite this, it sucks. Seriously.
通常这是一个好兆头,表明我已经完成了当晚的编码会话。
// remember to comment code
什么?:D
像这样的东西:
// This method takes two integer values and adds them together via the built-in
// .NET functionality. It would be possible to code the arithmetic function
// by hand, but since .NET provides it, that would be a waste of time
private int Add(int i, int j) // i is the first value, j is the second value
{
// add the numbers together using the .NET "+" operator
int z = i + j;
// return the value to the calling function
// return z;
// this code was updated to simplify the return statement, eliminating the need
// for a separate variable.
// this statement performs the add functionality using the + operator on the two
// parameter values, and then returns the result to the calling function
return i + j;
}
等等。
每条只是重复代码所说的注释都是无用的。评论不应该告诉我代码的作用。如果我对编程语言不够了解,仅仅通过阅读代码来理解发生了什么,我根本不应该阅读该代码。评论喜欢
// Increase i by one
i++;
完全没用。我看到 i 增加了 1,这就是代码所说的,我不需要对此发表评论!注释应该用来解释为什么要做某事(如果它远非显而易见)或为什么以这种方式而不是任何其他方式来做某事(这样我就可以理解另一个程序员做出的某些设计决策,这些决策在一次)。进一步的注释对于解释棘手的代码很有用,其中绝对不可能通过快速查看代码来确定发生了什么(例如,有一些棘手的算法来计算数字中设置的位数;如果你不知道这段代码做了什么,你就没有机会猜测那里发生了什么)。
Thread.Sleep(1000); // this will fix .NET's crappy threading implementation
我曾经用一个奇怪的 C 编译器参与过一个项目。除非在两个语句之间插入注释,否则它会在有效代码段上出错。所以我把评论改成:
// Do not remove this comment else compilation will fail.
而且效果很好。
我不相信。我是在得到 22 个答案后才提出这个问题的,但没有人指出最不实用的评论类型:
错误的评论。
人们写多余的注释妨碍了代码的理解,这已经够糟糕了,但是当有人写了详细的注释来解释某事是如何工作的时,它要么一开始就错了,要么在没有更改注释的情况下更改了代码之后就错了(更有可能的情况),这绝对是最糟糕的评论。
GhostDoc 自己提出了一些非常有趣的方法。
/// <summary>
/// Toes the foo.
/// </summary>
/// <returns></returns>
public Foo ToFoo()
// secret sauce
// Don't know why we have to do this
try
{
...some code...
}
catch
{
// Just don't crash, it wasn't that important anyway.
}
*叹
曾经遇到过一个文件。数千行代码,其中大部分非常可怕。命名错误的变量、棘手的循环条件以及隐藏在文件中间的一条注释。
/* Hmmm. A bit tricky. */
//' OOOO oooo that smell!! Can't you smell that smell!??!??!!!!11!??/!!!!!1!!!!!!1
If Not Me.CurrentMenuItem.Parent Is Nothing Then
For Each childMenuItem As MenuItem In aMenuItem.Children
do something
Next
If Not Me.CurrentMenuItem.Parent.Parent Is Nothing Then
//'item is at least a grand child
For Each childMenuItem As MenuItem In aMenuItem.Children
For Each grandchildMenuItem As MenuItem In childMenuItem.Children
do something
Next
Next
If Not Me.CurrentMenuItem.Parent.Parent.Parent Is Nothing Then
//'item is at least a grand grand child
For Each childMenuItem As MenuItem In aMenuItem.Children
For Each grandchildMenuItem As MenuItem In childMenuItem.Children
For Each grandgrandchildMenuItem As MenuItem In grandchildMenuItem.Children
do something
Next
Next
Next
End If
End If
End If
IDE 插入的默认注释。
我参与的最后一个使用 WebSphere Application Developer 的项目有很多维护开发人员和承包商,他们似乎并没有被数百甚至数千个包含以下内容的 Java 类所困扰:
/**
* @author SomeUserWhoShouldKnowBetter
*
* To change this generated comment edit the template variable "typecomment":
* Window>Preferences>Java>Templates.
* To enable and disable the creation of type comments go to
* Window>Preferences>Java>Code Generation.
*/
在认为您实际上找到了一个注释良好的源文件和意识到,是的,它是另一个默认注释,它迫使您使用SWEAR_WORD_OF_CHOICE
.
我昨天在 C# 应用程序中看到了这条评论:
//TODO: Remove this comment.
我最喜欢的所有时间评论。
/* our second do loop */
do {
不管是谁写的——你知道你是谁。
多年前 C 语言中的一个非常大的数据库引擎项目 - 数千行代码,变量名称短且拼写错误,没有注释......直到嵌套 if 条件深入到模块中数千行出现以下注释:
//if you get here then you really f**ked
到那时,我想我们已经知道了!
在一个巨大的 VB5 应用程序中
dim J
J = 0 'magic
J = J 'more magic
for J=1 to 100
...do stuff...
引用显然是THIS ... 是的,没有这两行的应用程序在运行时失败并出现未知错误代码。我们仍然不知道为什么。
摘自我的一篇博文:
在清理我管理的一个项目的一些源代码的过程中,我遇到了以下评论:
/*
MAB 08-05-2004: Who wrote this routine? When did they do it? Who should
I call if I have questions about it? It's worth it to have a good header
here. It should helps to set context, it should identify the author
(hero or culprit!), including contact information, so that anyone who has
questions can call or email. It's useful to have the date noted, and a
brief statement of intention. On the other hand, this isn't meant to be
busy work; it's meant to make maintenance easier--so don't go overboard.
One other good reason to put your name on it: take credit! This is your
craft
*/
然后再往下一点:
#include "xxxMsg.h" // xxx messages
/*
MAB 08-05-2004: With respect to the comment above, I gathered that
from the filename. I think I need either more or less here. For one
thing, xxxMsg.h is automatically generated from the .mc file. That might
be interesting information. Another thing is that xxxMsg.h should NOT be
added to source control, because it's auto-generated. Alternatively,
don't bother with a comment at all.
*/
然后又一次:
/*
MAB 08-05-2004: Defining a keyword?? This seems problemmatic [sic],
in principle if not in practice. Is this a common idiom?
*/
AHHHRRRGGHHH 刚刚在一些古老的代码中发现了这个,打赌这家伙认为他很有趣
private
//PRIVATE means PRIVATE so no comments for you
function LoadIt(IntID: Integer): Integer;
最糟糕的评论是对代码功能的错误解释。这比根本没有评论更糟糕。
我在代码中看到过这种带有太多注释的事情(不应该存在,因为代码本身就足够清晰),并且它主要发生在代码更新(重构、修改等)时但评论并没有随之更新。
一个好的经验法则是:只写注释来解释代码为什么做某事,而不是它做了什么。
肯定必须是代替错误处理的注释。
if(some_condition){
do_stuff();
}
else{
//An error occurred!
}
我刚刚找到了这个,写在注释掉的代码行之前的行上:
//This causes a crash for some reason. I know the real reason but it doesn't fit on this line.
从 vb6 移植到 vb.net 的 100k LOC 应用程序。看起来好像以前的开发人员在一个方法上放置了一个注释标题,然后将确切的注释复制并粘贴到他从那时起编写的每个方法上。数百种方法,每一种都被错误地注释了……
当我第一次看到它时,我笑了…… 6 个月后,这个笑话变得越来越淡了。
这是来自数据库触发器的绝对真实示例:
/******************************************************************************
NAME: (repeat the trigger name)
PURPOSE: To perform work as each row is inserted or updated.
REVISIONS:
Ver Date Author Description
--------- ---------- --------------- ------------------------------------
1.0 27.6.2000 1. Created this trigger.
PARAMETERS:
INPUT:
OUTPUT:
RETURNED VALUE:
CALLED BY:
CALLS:
EXAMPLE USE:
ASSUMPTIONS:
LIMITATIONS:
ALGORITHM:
NOTES:
******************************************************************************/
/** function header comments required to pass checkstyle */
我见过的最无用的两条评论...
try
{
...
}
catch
{
// TODO: something catchy
}
我也在 Daily WTF 上发布了这个,所以我会把它修剪成评论......
// TODO: The following if block should be reduced to one return statememt:
// return Regex.IsMatch(strTest, NAME_CHARS);
if (!Regex.IsMatch(strTest, NAME_CHARS))
return false;
else
return true;
我从来没有发现非常有用的一个:
<!--- Lasciate ogne speranza, voi ch'intrate --->
只是典型的 Comp Sci 101 类型注释:
如果我的学生在作业中这样做,我会以随机的极端暴力行为威胁他们。他们仍然做到了。然而,他们似乎完全失去了正确缩进的意义。我想这说明了为什么 Python 会成为初学者的理想语言。
由自动 javadoc 工具(例如JAutoDoc)生成的注释。我让一个团队成员提交了大量的代码,评论如下:
/**
* Gets the something
*
* @param num The num
* @param offset The offset
*/
public void getSomething(int num, bool offset)
也许它作为一个起点是有帮助的,但根据定义,如果程序正在解析变量和方法名称以使其注释它不会有太大用处。
每当我用 C++ 或 Java 教授 OOP 时,我通常会得到以下信息:
// My class!
Class myclass
{
//Default constructor
public myClass()
{
...
}
}
我的政策是向学生宣布,他们将因文件不足和多余而被扣分
我有很多这样的:
# For each pose in the document
doc.elements.each('//pose') do |pose| ...
# For each sprite in sprites
@sprites.each do |sprite| ...
# For each X in Y
for X in Y do ...
不过,我正试图减少这一点。:(
#include <stdio.h>
//why isn't this working!
使用仅支持/*-style */
全局注释的 c 编译器。
我们维护着糟糕的 PHP 应用程序,原始开发人员习惯于将“调试代码”注释掉。正如他常说的那样,这是因为“如果他再次需要它们,他只需取消注释它们,瞧,这样可以为他节省很多工作”。
所以所有的脚本实际上都充满了这样的行:
//echo "asdfada";
//echo $query."afadfadf";
它们中没有一个实际上以任何方式起作用。他们主要是为了确认代码执行达到那个点。
在相关说明中,他从未删除过任何过时的脚本或数据库表。因此,我们的目录中充满了诸如 dosomething.php、dsomething1.php、dsomething1.bak、dsomething1.bak.php 等文件……每个人都害怕删除任何内容,因为没有人知道真正使用了什么。
我的研究涉及 API 可用性,我遇到了很多不好的评论,因为它们具有误导性、错位、不正确或不完整。
例如,在 Java 消息传递服务(JMS 或 J2EE 中)中,QueueReceiver.receive 类包含以下 gem:“此调用阻塞,直到消息到达、超时到期或此消息使用者关闭。零超时永不过期并且通话会无限期地阻塞。”
听起来不错?对?
问题是,正如我的实验室研究表明的那样,用户认为评论涵盖了所有内容。面对收不到信息的情况,他们拒绝到别处寻找解释。
在这种情况下,当您从 QueueConnectionFactory 创建 QueueConnection 时,它会告诉您在调用 start 之前不会传递消息。但这并没有出现在接收方法中。
我相信如果没有这条线,更多的人会在别处搜索它。
顺便说一句,我的研究一般涉及 JavaDoc 的可用性,以及人们是否真的在 JavaDocs 中找到了重要的指令。如果有人想看看,相关的就在这里。
我有这样做的一个非常坏的习惯,尤其是当我在滚动时:
// TODO: Documentation.
一个非常大的源文件,在单个进程中实现多线程。在所有调用堆栈切换和信号量抓取以及线程暂停和恢复中,有一个关于指针操作的特别模糊位的简单注释:
/* Trickiness */
恩,谢谢分享。
无关的评论中断。通常,如果存在逻辑上的流分离,则一行注释如下:
/***************************************************************************/
在该部分代码的上方和下方可能会有所帮助。当您需要稍后返回并将一个大函数(开始时很小)拆分为几个较小的函数以保持代码易于阅读时,它也很不错。
一位不愿透露姓名的前程序员决定添加以下两行:
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
在每一行代码之后。
一旦我在某些代码中看到以下注释:
//I know that this is very ugly, but I am tired and in a hurry.
//You would do the same if you were me...
//...
//[A piece of nasty code here]
这是我最喜欢的两个:
// do nothing
这并没有真正的帮助,因为它只是占用空间。
然后在更远的地方:
// TODO: DAN to fix this. Not Wes. No sir. Not Wes.
我想如果我不是丹或韦斯,我应该忽略这个,对吧?
cntrVal = ""+ toInteger(cntrVal) //<---MAYBE THIS IS THE WAY I'M GOING THROUGH CHANGES (comin' up comin' up) THIS IS THE WAY I WANNA LIVE
顺便说一句,那是E型歌曲的歌词...
过度冗余并不能说明发生了什么。这个来自手机固件
/*========================================================================
FUNCTION
DtFld_SetMin
DESCRIPTION
This local function sets a nMin member of the Dtfld struct.
DEPENDENCIES
None
ARGUMENTS
[in]me
Pointer to the Dtfld struct.
[in]val
Value to set
RETURN VALUE
None.
SIDE EFFECTS
None
NOTE
None
========================================================================*/
/**
@brief This local function sets a nMin member of the Dtfld struct..
@param [in] me Pointer to the Dtfld struct.
@param [in]val Value to set
@retval None
@note None
@see None
*/
static __inline void DtFld_SetMin(DtFld *me, int val)
{
me->nMin = val;
}
// initialise the static variable to 0
count = 1;
不完全是评论,而是来自描述我曾经不得不使用的系统 API 的 JavaDoc。
setAttribute(attributeName, attributeValue) 设置一个属性
它没有记录什么是属性(它们不是 HTML/XML/etc 属性),存在哪些属性或它们可以具有哪些值。
/* FIXME: documentation for the bellow functionality - and why are we doing it this way */
对于会计应用程序来说,这是一个庞大的统计程序。我们从来没有弄清楚她为什么这样做——错误的——方式。但我们不得不重写它,并为客户支付了罚款。
// Magic
menu.Visible = False
menu.Visible = True
这是来自我曾经处理过的一些 PowerBuilder 代码中的 UI 框架。框架动态创建菜单项(从数据库数据)。但是,当 PowerBuilder 从 16 位升级到 32 位时,菜单代码停止工作。首席开发人员以某种方式确定隐藏菜单然后显示它会导致它正确显示。
曾几何时,我看到:
#region This is ugly but a mas has to do what a man has to do
Initialization of a gigantic array (...)
#endregion
// Aren't you glad this has ended?
我很高兴我不是那个开发者。
我很惊讶以前没有人发布过这样的帖子。
#contentWrapper{
position:absolute;
top: 150px; /*80 = 30 + 50 where 50 is margin and 30 is the height of the header*/
}
完全错误的评论是最糟糕的评论。
// 祝你好运
/// <summary>
/// Disables the web part. (Virtual method)
/// </summary>
public virtual void EnableWebPart() { /* nothing - you have to override it */ }
我使用两种语言(英语和法语)工作,但我最喜欢的评论是法语:
/* La passe du coyote qui tousse */
翻译它会给出这样的东西:
/* The coughing coyote trick */
它通常代表一段代码,或者对作者来说似乎是一个聪明的想法并且完全晦涩难懂,或者它是一个奇怪的错误修复,甚至作者都不明白它为什么起作用(想想通过移动 if 语句来修复竞争条件)。在所有情况下,都是写得不好的代码吓坏了任何不得不重构它的人,因为很难预测改变它的效果。
add ax,1 ;add 1 to the accumulator
严重地?那条评论浪费了我生命中的 5 秒。
还有过时的评论 FTL
//the system can only handle 5 people right now. make sure where not over
if(num_people>20){
我遇到过的最有趣的事情之一。
// HACK HACK HACK. REMOVE THIS ONCE MARLETT IS AROUND
一个让我想知道的。
// this is a comment - don't delete
// yes, this is going to break in 2089, but, one, I'll be dead, and two, we really ought to be using
// a different system by then
if (yearPart >= 89)
{
// naughty bits removed....
}
(评论没有用,但都是真实的陈述。)
我刚刚在一个软件的 INI 文件中看到了这一点(不久前转储给我的几个软件之一)我正在维护:
;--- if LOGERR=1, errors are logged but debugging is difficult
;--- if LOGERR=0, errors are not logged but debugging is easy
LOGERR=1
嗯,调试确实很难,但我不敢改变设置。
我已删除名称以避免尴尬,但这是在某些生产代码中发现的注释。不幸的是,由于这是 ASP 代码,指的是一个 VB6 模块,并且客户非常好奇,当我在咨询访问期间在现场时,是她向我指出了评论。幸运的是,她对此有幽默感。
'我不知道这个@"%& 的帮助是如何工作的。它是由那个承包商创建的一大堆 &£$! ---------。
我将把它留在原处,希望没有人永远需要它改变。
不幸的是,大约一年后代码确实需要更改,此时我们发现我们没有源代码,不得不将其丢弃并免费重写。
我不得不说,我遇到的最没用的评论类型是第二语言评论。
我宁愿看到用某人的母语清楚地写下的评论,也不愿看到用非常差的近似英语潦草写的评论。至少那时该语言的母语人士可以翻译它。ESL 评论通常对地球上的每个人来说都是不可读的,除了写它们的人,有时甚至不是他们自己。
取自遗留代码,这是对以下if
条件目的的唯一描述(条件跨越 120 列的 4 行):
#-- Whoa, now that's a big if condition.
从记忆中引用此内容,因此可能不准确。
我不知道这他妈的是做什么的,但它似乎有效,所以我没有碰它。
有趣的是我发现它的方式。此评论嵌入在我们公司的某个开发人员为客户编写的访问应用程序中,并在 MDB 中分发。不幸的是,“似乎工作”的代码被轰炸了,Access 尽职尽责地打开了代码窗口,调试器突出显示了注释正下方的行。它并没有完全激发该客户的信心。
某人的名字或首字母缩写,仅此而已。有时这些签名定义了一个代码块......
//SFD Start
...code...
//SFD End
就像代码是这样的艺术品,他们必须签名!另外,如果其他人需要更改以这种方式标记的代码怎么办?
这不应该与源代码控制系统中的“责备”或“注释”功能相混淆——它们太棒了!
今天跑了一圈。我应该预料到它是 Excel 工作簿中 VBA 宏的一部分。
a.writeline s 'write line
我发现写这篇文章的人花时间写了一个评论,使用空格来清理令人难以置信的混乱的“writeline”命令,但没有发现使用有意义的变量名的必要性,我发现它特别迷人。最好我能说 a 是“a file”的缩写,s 是“a String”的缩写(因为“a”已经被占用了)。
随机,在代码中间:
//???
if (someFlag)
{
// YES
DoSomething();
}
else
{
// NO
DoSomethingElse();
}
有一个人经常这样做,团队的其他成员最终说服他停止这样做!
这:
是的,一个空格,作为颠覆性的更改日志留下。
我在地图产品的示例应用程序中发现了这一点:
// Return value does not matter
return 0;
我在一个扭曲的程序中发现了这个
# Let them send messages to the world
#del self.irc_PRIVMSG # By deleting the method? Hello?
/**
* Implements the PaymentType interface.
*/
public class PaymentTypePo implements PaymentType
我曾经与一位非常有才华的汇编语言程序员一起工作,他用许多宏扩展了基本的 ARM 指令集。他的代码由数万条指令组成,看起来像下面这样——我(一个称职的 ARM 程序员)无法阅读的宏指令由 ??? 以及偶尔的常规 ARM 指令,例如 ADD:
... ???R0,R0,#1 ???R0,R1 添加 R0,R0,#6 ; 添加 6 ???R1,R0 ???R0,R0,R1 ...
我只能假设,当你的大脑有一颗行星那么大时,应付那些过于简单的讨厌指令就太高调了。
今天在一堆声明的中间找到了这个:
// other variables
啧啧,真的吗?谢谢。
我曾经在一个 VB.NET 应用程序中遇到过这个小美女
Dim huh as String 'Best name for a variable ever.
// 返回
返回;
今天才发现这个。。。
// TODO: this is basically a copy of the code at line 743!!!
这是我在我小组大学期末项目的文件中写的评论
/* http://youtube.com/watch?v=oHg5SJYRHA0 */
我们在工作中经常拿来开玩笑的经典(有错别字):
// Its stupid but it work
这在旧代码库中多次被发现。
我必须修复 2000 行代码中的一个错误,该代码将音频从 GSM 转码为 mu-law(主要使用位移和转换值数组)。文件中唯一的注释位于其中定义的唯一方法的顶部。它是:
/* Do the business */
// Undocumented
我曾经维护我们为 Harris 小型机定制的操作系统代码(是的,这是很久以前的事了)。有一天,通过调度程序代码(汇编程序),我遇到了一个代码块,顶部有注释“Begin Magic”,大约 25 行后有注释“End Magic”。中间的代码是我见过的最紧凑、最复杂、最优雅的代码。我们花了 4 个人来弄清楚那一小段代码实际上在做什么(VM 切换)。
我正在对一个超过 1000 行但没有任何注释的 java 类进行一些更改。我是他们编码风格的新手,所以我忍不住要添加类似的评论
/*Added because someone asked me to add it*/
if (returnValue ==0)
doStuff();
else
System.out.println("Beware of you, the Dragons are coming!");
/* this is a hack.
ToDo: change this code */
//I am not sure why this works but it fixes the problem.
这个是我无用评论的榜首。
// this is messed up, and no one actually knows how it works anymore...
有人发给我一个 ac 文件,其中描述了他的程序创建的二进制文件。
除了写真实数据的某处外,它不包含任何评论
SwapArray(..); // Big endian ???
write();
我询问了 SwapArray 的实现,他告诉我我不需要它,只是为了确保它可以在 linux 机器上运行。
经过实验,我发现他到处都使用小端(这和正常情况一样),但只有真正的数据是用大端写入的。通常你可以在十六进制编辑器中看到它,但数据是以浮点存储的,所以不容易注意到混合端。
流行音乐之巅肯定是
// This code should never be called
当我在一个遗留通信应用程序上工作时,我最喜欢。
// Magic happens here...
今天遇到这个:
/// <summary>
/// The Page_Load runs when the page loads
/// </summary>
private void Page_Load(Object sender, EventArgs e) {}
另一个我记得的:
//TODO: This needs to be reworked. THIS CRAP NEEDS TO STOP!!!
{
Long complicated code logic //Added this
}
{Some Code;} // 我不记得我为什么要这样做,但它确实有效......
其实我有几个
// 18042009: (Name here) made me do this
对这些评论不是很自豪,但我保留它们是为了提醒我为什么我对特定部分进行 WTF 编码,在这方面非常有用。
我最近在我很久以前写的一些代码中发现了这一点:
// it's a kind of magic (number)
$descr_id = 2;
$url_id = 34;
这条评论实际上是用不同的语言写的,但我会尝试在翻译中传达这种效果:
//we trick it, if forbidden, as if it had already existed
评论试图描述的是它处理已关闭的列表项的方式 - 代码将该项标记为重复项,因此应跳过。是的,这是一种非常低调的做事方式,但与荒谬的评论相比,它显得苍白无力。
[some code]
// [a commented out code line]
// this line added 2004-10-24 by JD.
// removed again 2004-11-05 by JD.
// [another commented out code line]
[some more code]
a) 为什么?b) 哪条线?
我在游戏的 AI 部分看到了一段很棒的代码:
..."AI code"...
if(something)
goto MyAwesomeLabel; //Who's gonna be the first to dump crap on me for this?
..."More Ai code"...
MyAwesomeLabel:
//It wasn't that hard to get here, right?
..."Even more AI code"...
//URGENT TODO:重新实现这个狗屎,旧代码已经坏得要命了……我们坚持我们解决了所有问题
刚刚在我的一个旧项目中发现了这一点。起初我笑了,但最后我很生气,因为我仍然找不到错误。
# Below is stub documentation for your module. You'd better edit it
不太适合这个问题,但我讨厌看到:
try
{
someSeeminglyTrivialMethod();
}
catch (Exception e)
{
//Ignore. Should never happen.
}
每当我在代码审查期间看到这一点时,我都会告诉他们将 catch 替换为:
catch (Exception e)
{
System.exit(0);
}
我认为这是对 SO 帖子的最糟糕评论,并且很失望地发现并非如此。
注释代码是最没用的注释 :)