コードにコメントを付けることは、コードを次の人に、あるいは6か月かそこらで自分自身にさえ理解できるようにするためのコーディングスタイルの重要な部分であることは誰もが知っています。
ただし、コメントでマスタードが切れない場合もあります。私は明白なジョークやベントされたフラストラトンについて話しているのではなく、説明を試みているように見えるコメントについて話しているのですが、あまりにも貧弱なことをしていると、そこにいない可能性があります。コメントが短すぎる、不可解である、または単に間違っている。
おとぎ話として、あなたが見た中で本当にひどいものを共有できますか？それが明らかでない場合は、それが参照しているコードを示し、それの何が悪いのかを指摘してください。代わりにそこに何を入れるべきでしたか？
参照：
典型的なCompSci101タイプのコメント：
$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 ボイラープレート コメントは特に役に立ちません。彼らは何の役にも立たずに多くの画面領域を消費します。そして最悪の部分は、そのようなコメントが 1 つ表示されると、他の何百ものコメントが背後に潜んでいることです。
/**
* 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 コンパイラを使ったプロジェクトに取り組んだことがあります。2 つのステートメントの間にコメントが挿入されていない限り、有効なコードに対してエラーが発生しました。そこで、コメントを次のように変更しました。
// 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.
}
*はぁ
一度ファイルに出くわしました。数千行のコード、そのほとんどは非常に恐ろしいものです。不適切な名前の変数、ループのトリッキーな条件、ファイルの途中に埋め込まれた 1 つのコメント。
/* 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
その時までに、私たちはすでにそれを知っていたと思います!
AHHHRRRGGGHHH 古代のコードでこれを見つけたんだけど、彼は自分がかなり面白いと思ったに違いない
private
//PRIVATE means PRIVATE so no comments for you
function LoadIt(IntID: Integer): Integer;
巨大な VB5 アプリケーションで
dim J
J = 0 'magic
J = J 'more magic
for J=1 to 100
...do stuff...
参照は明らかにこれです...そして、はい、これらの2行のないアプリケーションは、実行時に不明なエラーコードで失敗します。その理由はまだわかりません。
私のブログ投稿の1つから取られた：
私が管理しているプロジェクトの 1 つのソース コードの一部をクリーンアップする過程で、次のコメントに出くわしました。
/*
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?
*/
最悪のコメントは、コードが何をするかについて間違った説明をするコメントです。それは、まったくコメントしないよりも悪いことです。
私はこの種のことをコードで見たことがありますが、コメントが多すぎます (コードはそれ自体で十分に明確であるため、そこにあるべきではありません)。これは主に、コードが更新されたとき (リファクタリング、変更など) に発生します。しかし、コメントはそれに伴って更新されません。
経験則としては、コードが何をするかではなく、コードが何かをする理由を説明するコメントだけを書くことです。
コメントアウトされたコード行の前の行に書かれたこれを見つけました：
//This causes a crash for some reason. I know the real reason but it doesn't fit on this line.
エラー処理の代わりにコメントを付ける必要があります。
if(some_condition){
do_stuff();
}
else{
//An error occurred!
}
vb6 から vb.net に移植された 100k LOC アプリケーション。以前の開発者が 1 つのメソッドにコメント ヘッダーを付けてから、それ以降に記述したすべてのメソッドに正確なコメントをコピー アンド ペーストしたようです。何百ものメソッドとそれぞれが間違ってコメントしています...
最初に見たときは笑いました... 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 */
私が非常に役立つと思ったことのないもの：
<!--- Lasciate ogne speranza, voi ch'intrate --->
私が今まで見た中で最も役に立たない2つのコメント...
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;
私たちはPHPアプリケーションのひどい混乱を維持しており、元の開発者はその場所に「デバッグコード」をコメントアウトしたままにする習慣がありました。彼がいつも言っていたように、それは「彼が再びそれらを必要とする場合に備えて、彼はそれらのコメントを外して出来上がり、それは彼に多くの仕事を節約する」からでした。
したがって、すべてのスクリプトは文字通り次のような行でいっぱいです。
//echo "asdfada";
//echo $query."afadfadf";
それらのどれも実際には機能していません。それらは主に、コードの実行がそのポイントに到達したことを確認するためにあります。
関連するメモとして、彼は廃止されたスクリプトやデータベーステーブルを削除したことはありません。したがって、dosomething.php、dosomething1.php、dosomething1.bak、dosomething1.bak.phpなどのファイルで満たされたディレクトリがあります...誰もが実際に使用されているものを知らないため、誰もが何かを削除することを恐れています。
#include <stdio.h>
//why isn't this working!
/*-style */グローバルコメントのみをサポートするc-compilerを使用します。
自動 javadoc ツール (例: JAutoDoc ) によって生成されたコメント。チームメンバーに、次のようなコメントが付けられた大量のコードを提出してもらいました。
/**
* Gets the something
*
* @param num The num
* @param offset The offset
*/
public void getSomething(int num, bool offset)
出発点としては役立つかもしれませんが、定義上、プログラムが変数名とメソッド名を解析してコメントを作成している場合、あまり役に立ちません。
私はこれらの多くを持っています：
# 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 ...
しかし、私はそれを削減しようとしています。:(
典型的な Comp Sci 101 タイプのコメント:
私は、生徒が課題でこれを行った場合、極端な暴力行為をランダムに行うと脅しました。そして、彼らはまだそうしました。しかし、適切なインデントの意味は完全に失われているように見えました。Python が初心者にとって理想的な言語である理由を示していると思います。
私が C++ や Java で OOP を教えるときはいつでも、通常、次のことを学びます。
// My class!
Class myclass
{
//Default constructor
public myClass()
{
...
}
}
私のポリシーは、不十分な書類と余分な書類の両方で減点されることを学生に通知することです
私の研究はAPIの使いやすさを扱っており、誤解を招く、置き忘れた、正しくない、または不完全であるという理由だけで悪いコメントをたくさん目にしました。
たとえば、Javaメッセージングサービス（JMSまたはJ2EE内）では、QueueReceiver.receiveクラスに次のgemが含まれています。「この呼び出しは、メッセージが到着するか、タイムアウトが期限切れになるか、このメッセージコンシューマが閉じられるまでブロックされます。ゼロのタイムアウトが期限切れになることはありません。呼び出しは無期限にブロックされます。」
いいね？右？
問題は、私のラボの調査が示すように、コメントがすべてをカバーしているとユーザーが信じていることです。メッセージが届かない状況に直面して、彼らは説明を他の場所で探すことを拒否します。
この場合、QueueConnectionFactoryからQueueConnectionを作成すると、startが呼び出されるまでメッセージが配信されないことが通知されます。しかし、それはreceiveメソッドには表示されません。
その線がなかったら、もっと多くの人が他の場所でそれを探していただろうと私は信じています。
ちなみに、私の研究では、JavaDocのユーザビリティ全般と、人々が実際にJavaDocsで重要なディレクティブを見つけるかどうかを扱っています。誰かが見てみたいなら、関連はここにあります。
過度の冗長性は、何が起こっているのかを明確にしません。これは携帯電話のファームウェアからのものです
/*========================================================================
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;
}
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タイプの曲の歌詞です…
ここに私の2つのお気に入りがあります：
// do nothing
スペースを占有するだけなので、これはあまり役に立ちません。
次に、さらにどこかで：
// TODO: DAN to fix this. Not Wes. No sir. Not Wes.
私がダンでもウェスでもないなら、これは無視するべきだと思いますよね？
余分なコメントが中断されます。通常、フローの論理的な分離がある場合、次のようなコメント行があります。
/***************************************************************************/
コードのそのセクションの上と下が役に立ちます。また、コードを読みやすくするために、後で戻ってきて大きな関数 (最初は小さな関数) をいくつかの小さな関数に分割する必要がある場合にも便利です。
無名のままでいる元プログラマーは、次の2行を追加することにしました。
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
コードのすべての行の後。
あるコードで次のコメントを見たら：
//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]
特に私が順調に進んでいるときに、これを行う非常に悪い習慣があります。
// TODO: Documentation.
1 つのプロセスでマルチスレッドを実装する、非常に大きなソース ファイル。すべての呼び出しスタックの切り替え、セマフォの取得、スレッドの一時停止と再開の最中に、特にあいまいなポインター操作に関する簡単なコメントがありました。
/* Trickiness */
シェアしてくれてありがとう。
// initialise the static variable to 0
count = 1;
/// <summary>
/// Disables the web part. (Virtual method)
/// </summary>
public virtual void EnableWebPart() { /* nothing - you have to override it */ }
私はこれをソフトウェアのINIファイルで見たばかりです（少し前に私にダンプされたいくつかのファイルの1つ）私は維持しています：
;--- if LOGERR=1, errors are logged but debugging is difficult
;--- if LOGERR=0, errors are not logged but debugging is easy
LOGERR=1
さて、デバッグは確かに難しかったですが、私はあえて設定を変更しませんでした。
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){
// 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....
}
（コメントとしては役に立ちませんが、どちらも真実のステートメントです。）
// Magic
menu.Visible = False
menu.Visible = True
これは、私が以前取り組んでいた PowerBuilder コードの UI フレームワークからのものです。フレームワークは、(データベース データから) メニュー項目を動的に作成しました。ただし、PowerBuilder を 16 ビットから 32 ビットにアップグレードすると、メニュー コードが機能しなくなりました。主任開発者は、メニューを非表示にしてから表示すると、メニューが正しく表示されるとどういうわけか判断しました。
私は 2 つの言語 (英語とフランス語) で仕事をしていますが、私のお気に入りのコメントはフランス語でした。
/* La passe du coyote qui tousse */
翻訳すると、次のようになります。
/* The coughing coyote trick */
これは通常、作成者には巧妙なアイデアのように見えて完全にあいまいであったか、作成者でさえそれが機能する理由を理解していない奇妙なバグ修正であったコードの一部を表しています (if ステートメントを移動して競合状態を修正することを考えてみてください)。すべての場合において、コードを変更した場合の影響を予測するのが非常に困難だったため、コードをリファクタリングしなければならなかった人を怖がらせたのは、不十分に作成されたコードでした。
かなりのコメントではありませんが、私がかつて使用しなければならなかったシステムの API を説明した JavaDoc からです。
setAttribute(attributeName, attributeValue) 属性を 設定します
属性が何であるか (それらは HTML/XML/etc 属性ではありません)、存在する属性、またはそれらが持つことができる値はどこにも文書化されていませんでした。
これまで誰もこのような投稿をしなかったことに驚いています。
#contentWrapper{
position:absolute;
top: 150px; /*80 = 30 + 50 where 50 is margin and 30 is the height of the header*/
}
単純に間違ったコメントは、最悪の種類のコメントです。
/* FIXME: documentation for the bellow functionality - and why are we doing it this way */
これは、会計アプリケーション用の巨大な統計プログラムでした。私たちは、なぜ彼女がそれを - 間違った - 方法で行ったのか理解できませんでした. しかし、私たちはそれを書き直さなければならず、顧客に違約金を支払いました。
// 幸運を
私が今まで出会った中で最も面白いものの1つ。
// HACK HACK HACK. REMOVE THIS ONCE MARLETT IS AROUND
不思議に思った一枚。
// this is a comment - don't delete
むかしむかし、私は見ました：
#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?
私はその開発者ではなくてよかったです。
オーディオをGSMからmu-lawにトランスコードする2000行のコードのバグを修正する必要がありました（主にビットシフトと変換値の配列を使用）。ファイル内の唯一のコメントは、ファイルで定義されている唯一のメソッドの先頭にありました。そうだった：
/* Do the business */
今日はおかしなことに出くわした。それがExcelワークブックのVBAマクロの一部であったことを考えると、私はそれを期待すべきでした。
a.writeline s 'write line
これを書いた人が、スペースを使って非常に紛らわしい「writeline」コマンドを片付けるコメントを書くのに時間がかかったのは特に魅力的でしたが、意味のある変数名を使用する必要はありませんでした。私が知る限り、aは「ファイル」の略であり、sは「文字列」の略です（「a」はすでに使用されているため）。
これ：
うん、空白スペース、Subversion変更ログとして残されています。
誰かの名前またはイニシャル、そしてそれだけです。これらの署名がコードのブロックを定義する場合があります...
//SFD Start
...code...
//SFD End
コードがそのような芸術作品であるように、彼らはそれに署名しなければなりません！さらに、他の誰かがこのようにマークされたコードを変更する必要がある場合はどうなりますか？
これは、ソース管理システムの「非難」または「注釈」機能と混同しないでください。
// Undocumented
私はかつて、Harrisミニコンピューター用にカスタマイズしたオペレーティングシステムコードを保守していました（はい、これはかなり前のことです）。ある日、スケジューラコード（アセンブラ）を調べてみると、上部に「Begin Magic」というコメントがあり、約25行後に「EndMagic」というコメントがあるコードブロックに出くわしました。その間のコードは、私が今まで見た中で最もタイトで、最も複雑で、エレガントなコードの一部でした。コードのその小さなセクションが実際に何をしているのか（VMスイッチング）を理解するのに4人かかりました。
私はかつて、いくつかのマクロで基本的なARM命令セットを拡張した非常に才能のあるアセンブリ言語プログラマーと協力していました。彼のコードは数万の命令で構成されており、次のようになりました-私（有能なARMプログラマー）が読み取ることができなかったマクロ命令を使用して、???で表されます。ADDのような時折の通常のARM命令：
..。 ??? R0、R0、＃1 ??? R0、R1 ADD R0、R0、＃6; 6を追加 ??? R1、R0 ??? R0、R0、R1 ..。
あなたが惑星の大きさの脳を持っているとき、それはあまりにも単純すぎるそれらの厄介な指示に対処するには高すぎる眉であると私は推測することができるだけです。
記憶からの引用なので正確ではないかもしれません。
これが何をするのかはわかりませんが、機能しているように見えるので、触れていません。
面白いのは、私がそれを知った方法です。このコメントは、当社のある開発者がクライアント用に作成し、MDB で配布したアクセス アプリケーションに埋め込まれていました。残念ながら、「動作しているように見える」コードが爆撃され、Access は忠実にコード ウィンドウを開き、デバッガーがコメントのすぐ下の行を強調表示しました。その顧客に対する信頼を正確に刺激するものではありませんでした。
if (someFlag)
{
// YES
DoSomething();
}
else
{
// NO
DoSomethingElse();
}
常にそれを行っていた一人の男がいて、チームの他のメンバーは最終的に彼にそれをやめるよう説得しました!
1000 行を超える Java クラスにいくつかの変更を加えていますが、コメントはありません。私は彼らのコーディングスタイルの初心者なので、次のようなコメントを追加することはできません
/*Added because someone asked me to add it*/
コードの途中でランダムに:
//???
マッピング製品のサンプル アプリケーションでこれを見つけました。
// Return value does not matter
return 0;
恥ずかしさを避けるために名前を削除しましたが、これは一部の製品コードに見られるコメントです。残念ながら、これは VB6 モジュールを参照する ASP コードであり、顧客は非常に好奇心旺盛だったので、私がコンサルタントの訪問中に現場にいたときに、私にコメントを指摘したのは彼女でした. 幸いなことに、彼女にはユーモアのセンスがありました。
「この @"%& がどのように機能するのかわかりません。その請負業者によって作成された大量の &£$! です ----------。
そのままにしておいて、誰もいないことを願っています。変更する必要があります。
残念なことに、約 1 年後にコードを変更する必要がありました。その時点で、ソース コードがないことがわかり、ジャンクして無料で書き直す必要がありました。
/**
* Implements the PaymentType interface.
*/
public class PaymentTypePo implements PaymentType
私はかつてVB.NETアプリでこの小さな美しさに出くわしました
Dim huh as String 'Best name for a variable ever.
// 戻る
戻る;
今日、宣言のブロックの途中でこれを見つけました：
// other variables
ねえ、本当に？ありがとう。
if (returnValue ==0)
doStuff();
else
System.out.println("Beware of you, the Dragons are coming!");
従来のコードから引用すると、これは次ifの条件の目的の唯一の説明です (条件は 120 列で 4 行にまたがっています)。
#-- Whoa, now that's a big if condition.
ねじれたプログラムでこれを見つけました
# Let them send messages to the world
#del self.irc_PRIVMSG # By deleting the method? Hello?
ちょうど今日これを見つけた...
// TODO: this is basically a copy of the code at line 743!!!
私が遭遇した中で最も役に立たないタイプのコメントは、第二言語のコメントであると言わざるを得ません。
私は、英語の非常に貧弱な概算で走り書きするよりも、誰かの母国語で明確に書かれたコメントを見たい. 少なくとも、その言語のネイティブ スピーカーはそれを翻訳できます。ESL のコメントは、多くの場合、それを書いた人を除いて、地球上のすべての人が読むことができません。
トップ・オブ・ザ・ポップスは確かに
// This code should never be called
質問に完全には適合していませんが、私は次のことを見ると嫌いです：
try
{
someSeeminglyTrivialMethod();
}
catch (Exception e)
{
//Ignore. Should never happen.
}
コードレビュー中にそれを見るときはいつでも、キャッチを次のように置き換えるように指示します。
catch (Exception e)
{
System.exit(0);
}
私は最近、何年も前に書いたいくつかのコードでこれを見つけました：
// it's a kind of magic (number)
$descr_id = 2;
$url_id = 34;
以前の通信アプリケーションに取り組んでいたときのお気に入りです。
// Magic happens here...
実は私もいくつか持っているのですが、
// 18042009: (Name here) made me do this
これらのコメントを誇りに思っているわけではありませんが、なぜその特定のセクションで WTF コードを作成したのかを思い出させるために残しています。
[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) どの行ですか?
// this is messed up, and no one actually knows how it works anymore...
今日これに出くわしました：
/// <summary>
/// The Page_Load runs when the page loads
/// </summary>
private void Page_Load(Object sender, EventArgs e) {}
{
Long complicated code logic //Added this
}
/* this is a hack.
ToDo: change this code */
誰かが、自分のプログラムが作成したバイナリ ファイルを記述した ac ファイルを送ってくれました。
実際のデータの書き込みのどこかを除いて、コメントは含まれていませんでした
SwapArray(..); // Big endian ???
write();
SwapArray の実装について尋ねたところ、Linux マシンで動作することを確認するためだけに必要ないとのことでした。
実験の結果、彼はどこでもリトル エンディアンを使用していたが (これは通常のようです)、実際のデータのみがビッグ エンディアンで記述されていることがわかりました。通常は 16 進エディタで表示できますが、データは浮動小数点で格納されているため、混合エンディアンに気付くのはそれほど簡単ではありません。
//緊急の TODO: このたわごとを再実装してください。古いコードは地獄のように壊れています...そして、すべての問題を解決したと思いました
私の古いプロジェクトの1つでそれを見つけました。最初は笑いましたが、それでもバグを見つけることができなかったので、最終的には愚痴をこぼしました。
{Some Code;} // なぜこれを行うのか覚えていませんが、うまくいきます...
# Below is stub documentation for your module. You'd better edit it
このコメントは実際には別の言語で書かれていますが、翻訳でその効果を伝えようとします。
//we trick it, if forbidden, as if it had already existed
コメントが説明しようとしていたのは、オフになっているリスト項目を処理する方法でした-コードは項目を重複としてマークしたため、スキップする必要があります。はい、非常に下品なやり方ですが、無意味なコメントと比較すると見劣りします。
//I am not sure why this works but it fixes the problem.
これは私の役に立たないコメントのリストのトップです。
私が覚えている別のもの：
//TODO: This needs to be reworked. THIS CRAP NEEDS TO STOP!!!
これは SO 投稿に対する最悪のコメントだと思っていましたが、そうではないことに失望しました。
Commented code is the least useful comment :)