TODOコメントは意味がありますか？
私はかなり大きなプロジェクトに取り組んでおり、そのためにいくつかの翻訳を行う仕事を得ました。翻訳されていないラベルがたくさんあり、コードを調べていると、この小さなコードが見つかりました
//TODO translations
これにより、自分（および他の人）に対するこれらのコメントの意味について考えました。なぜなら、ほとんどの開発者が特定のコードを実行した後、それが実行するはずのことを実行していると感じたからです。それを維持するか、新しい機能を追加します。このTODOが長期間失われるようにします。
このコメントを書くのは理にかなっていますか、それとも、開発者の焦点に留まっているホワイトボード/紙/何か他のものに書かれるべきですか？
私はhaveが発生することに対して// todoコメントを使用する傾向がありますが、すぐには実行できません。
また、私はそれらを追跡することを確認します-それらを検索し（Visual Studioには、そのようなコメントを一覧表示する素晴らしい機能があります）、確実にareが実行されます。
しかし、あなたが言うように、誰もがそれらについて勤勉であるわけではなく、多くのコメントのように、彼らは時間とともに腐敗する傾向があります。
これは個人的な好みのほうがいいと思います。何をする必要があるかを文書化して追跡する限り、それが// todo、ポストイットノート、またはホワイトボード（どこにあるか）に関係ありません。最終的には行動しないこともあります）。
最近のIDEはTODOコメントを認識し、それらは独自のパネル/ウィンドウ/タブに表示されるため、理論的には失われません（私はEclipseとVisual Studioの両方を考えています。それを認識します）。
FIXME、BEWAREなど、カスタマイズしたい追加のコメントワードを構成することもできます。ただし、プロジェクトの他の開発者は、IDEを同じ方法でカスタマイズする必要があります。
TODOは、失われるわけではありませんが、アプリケーションが「現時点で」適切に機能するために必要ではないものに関連することが多いため、ここで「理論的に」書きました。また、「現時点」は、プロジェクトのタイプ/サイズに応じて、5分から5年に及ぶ場合があります:-)
最後に、私の意見では、コードの適切な場所にそれらを配置し、コードのどこか他の場所よりも「どこで変更を行うべきか」という質問に正確に回答する方がより意味があります。
編集：Wikipediaの コメントに関する記事 に記述されているように、日付とTODOの所有者を含めることは、良い習慣と見なされます。
それはある程度理にかなっているかもしれませんが、少なくとも私はそれらを時々使用します。重要な点は、TODOやFIXMEなどの一貫したタグを使用して、単純なテキスト検索で簡単に見つけられるようにすることです。
たとえば、「quick 'n dirty」ソリューションは、次のようなラベル付けに便利です。
ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable
コードが想定されていることを実行し、誰も文句を言わない場合、コメントは害を及ぼしません。コードを美化する時間があれば、FIXMEラベルの検索から始めるのは簡単です。
私の業界では、すべての人が// todoエントリ。ただし、大規模なプロジェクトでは、カスタム属性が次のように定義されることがあります。
[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
public DateTime EntryDate { get; set; }
public string Description { get; set; }
public DeveloperNote(int year, int month, int day, string desc)
{
EntryDate = new DateTime(year, month, day);
Description = desc;
}
}
そして、メソッドはこのように装飾することができます...
[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]
そしてより高いupsがやって来て、これらを自動的に収穫することができます。単純な場合はやり過ぎかもしれません// todoリマインダーですが、効果的です。また、.NETプラットフォームが必要です。
TODOはコメントのサブフォームにすぎません。ライターが何を伝え、どのように伝えるかを熟知している場合、コメントは非常に役に立ちます。ユーモアのセンスは、ここで数年後にメンテナーを喜ばせるために少量で適用することもできます。
昨年、私のコードの一部が廃止されるという電話を受けました。私はそれが生産されており、16年間メンテナンスを生き延びたことにかなり感銘を受けました。したがって、コードが長時間続く可能性があることに注意してください。意図や将来のニーズなどについてのコメントは、コードを初めて見ている数年後の人を助けるのに大いに役立ちます。
私の経験では、状況によって異なります。主な要因は、チームがこれらの「小さな」コメントをフォローアップするのに十分な規律があるかどうかです。もしそうなら、そう、彼らは理にかなっています。そうでない場合、これらのコメントは時間の浪費であり、他のオプションを検討する必要がある場合があります。ストーリーカード。
個人的に私は時々TODOコメントを使用しますが、それらは通常短命であり、通常、1つ、2つ、または3つの非常に少数のコメントしかありません。私は何よりもコードベースのマーカーとしてそれらを使用しています。私がそれらの世話をするのにあまりにも長く待つと、私が「やるべきこと」が必要だと思っていたことを忘れてしまいます。
私の好みは常にこれらを使用せず、代わりに適切なストーリーカードやバックログなどを使用することです。 1つのタスクに対して1つのメカニズムを使用します。
私は以前それらを書いていたのですが、あなたは通常それらをフォローアップしていません。
そのため、現在は、忙しい作業を終えた直後に、作業したいものをマークするためにのみ使用しています。たとえば、私は新しい関数を実装し、使用する関数に小さなバグがあることに気付きました。私は現在のタスクで脱線しないようにこれを修正するFIXMEを作成します。
私を助けるために、コードにFIXMEがある場合、CIビルドは失敗するように設定されています:-)。
すぐに対処できない潜在的な問題に気づいた場合は、それらのチケット/バグ/問題を開きます。これにより、すべてのバグと同様に優先順位を付けることができます。これは、バグDBやコードにTODOとしての問題があるよりもはるかに良いと思います。
必要に応じて、バグIDを指定してTODOを追加できます:-)。
あなたがTODOまたはFIXMEを書いて、誰かが不確定な将来にそのコードに来たときに誰かがそれを修正するという考えを持っていれば、私は気にしないでください。彼らはコードを散らかし、この情報を収集するあなたのIDE=の報告部分を混乱させます。
役立つために、彼らはあなたのコードを（非常に）近い将来のためにブックマークする手段を提供するべきです。そうすれば、あなたはより適切な心の状態に早く戻ることができます。つまり、それらをコードに配置して、できるだけ早く削除します。
寿命が長いものは、実際にはそれが属するバグベースに配置する必要があります。
私たちの生活には十分なノイズがあります。他の場所で必要なときに注意を喚起するような新しいファンファーレを作成しないでください。
私の2セント
TODOコメントは、ある程度意味があると思います。特に（アジャイルショップやTDDショップで一般的なように）繰り返し作業をしている場合、areがやがて必要になるであろうけれども、迂回させたくないものがあります。その場で実装します。
醜いのは、そのようなコメントがコードベースに残っている場合です。機能に積極的に取り組んでいる間、それらを残してもかまいませんが、機能の完成に近づいたらすぐに、それらを取り除くことに集中する必要があります。それらを適切に機能するコードに実際に置き換える作業を行いたくない場合は、少なくとも関連する機能を除外してください。コードが最初に言う@JoonasPulakkaの例を借りる
ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable
あなたはそれを次のようなものに変えるかもしれません
ConnManager.getConnection(GetDatabaseName());
とりあえず、GetDatabaseName（）は、最初と同じ文字列を返すだけのスタブです。このようにして、将来の拡張の明確なポイントがあり、そこで行われた変更は、データベース名が必要な場所に反映されることがわかります。データベース名が中程度の総称でさえあれば、これは保守性の大幅な改善になる可能性があります。
個人的には、厳密にTODOではなく自分のキーワードを使用しますが、目的は同じです。また、コードをチェックインする前に、そのキーワードのグローバルソースコード検索を実行します。これは、通常、コードのどこにも表示されないように選択されています。見つかった場合、私は何かを忘れてしまったことを知っているので、先に進んで修正できます。
プログラマ名/署名をコメントに含めることに関しては、それはやりすぎだと思いますifソースコードのバージョン管理システムがあります（あなたdoでしょ？）。その場合、その非難機能は、コメントを追加したユーザー、より正確には、コメントに触れた変更を最後にチェックインしたユーザーを通知します。たとえば、Visual Studioでは、ソース管理機能の中にある「注釈」機能を使用してこれを簡単に実現できます。
通常、私は// TODOコメントを作成しませんが、それらすべてを個別のファイルに保存します。それでも簡単に管理できるオンラインソフトウェアを見つけられない/書き込めないので、短時間でもプロジェクトを開くと、今何をすべきかを忘れてTODOファイルを調べて作業を行うため、TODOファイルは依然として最も有用です。 。 「filename.cpp 354：Rebla this this bla bla bla」があり、ファイル内の// TODOコメントを検索するとはるかに便利です。怠惰なときに// TODO Earlerを実行しましたが、古い// TODO-をソースファイルから削除するだけで、プロジェクトが正常に機能している場合は修正しません。すべての// TODOをソースから別の場所に移動し、他のTodoと一緒に保持して、タスクの優先順位を簡単に設定できるようにすることを強くお勧めします。さまざまなファイルやさまざまなプロジェクトですべてのTODOを取得する場合、優先順位は本当に難しいTODOです。
素晴らしいと思いますが、一人ではありません。例えば：
//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice
このアプローチはかなりうまく機能しますが控えめです。例外をスローする習慣をつけて、一部のコードを完了するように促すのは、実際には最も専門的なアプローチとは言えません。しかし、あなたが何かを完了したと思う場合や、完了していない場合にあなたが完了したことを書き留める場合さえあり、私を救ってくれました。
ToDoコメントが他の100万件以上ある場合のタスクリストを作成する方法の大きな利点は、ToDoコメントがコードと一緒に移動するため、分離できないことです。
おそらく、このようなもののより適切な場所は、コードではなく課題追跡です。
すべてのTODOまたはFIXMEを正式なログに入力することを強くお勧めします。そうでない場合、それらは簡単に検索可能であり、未解決のTODOおよびFIXMEをチェックすることは、各反復のフェーズである必要があります。次に、これらをカタログ化して、すぐに対処できるように設定するか、チームが適切なタイミングで修正することを計画できます。
最後に、修正後は削除する必要があります。解決後に体系的に削除されない場合、効果が失われます。
結論：問題をまったく記録しないよりはましですが、実際にはそれらを維持する必要があります。