TODOコメントは意味がありますか？[閉まっている]

私はかなり大きなプロジェクトに取り組んでおり、そのためにいくつかの翻訳を行うタスクを受け取りました。翻訳されていないラベルがたくさんあり、コードを掘り下げていたときに、この小さなコードを見つけました

//TODO translations

これは私がこれらのコメントの意味を自分自身（そして他の人？）に考えさせましたそれを維持するか、新しい機能を追加します。これTODOは長い間失われます。

このコメントを書くことは理にかなっていますか、それとも開発者の焦点に留まるホワイトボード/紙/何かに書かれるべきですか？

私は、起こらなければならない// todoことにコメントを使う傾向がありますが、すぐにはできません。

また、それらを追いかけていることを確認します-それらを検索し（Visual Studioには、そのようなコメントを一覧表示する素晴らしい機能があります）、物事が完了していることを確認します。

しかし、あなたが言うように、誰もが彼らについて熱心ではなく、多くのコメントのように、彼らは時間とともに腐る傾向があります。

これは個人的な好みだと思います-何をする必要があるかを文書化して追いかけている限り、それがにあるか// 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コメントの代わりにJIRA（またはその他）のエントリを作成することをお勧めし// 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")]

そして、より高いアップが来て、これらを自動的に収穫することができます。簡単な// todoリマインダーではやり過ぎかもしれませんが、効果的です。また、.NETプラットフォームが必要です。

TODOは単なるコメントのサブフォームです。筆者が何を伝え、どのように伝えるかを知っている場合、コメントは非常に有用です。ユーモアのセンスは、数年後にメンテナーを喜ばせるために、ここでも少量で適用できます。

昨年、私のコードの一部が廃止されるという連絡を受けました。私はそれが生産されていて、16年間メンテナンスを生き延びたことにかなり感銘を受けました。したがって、コードは長時間続く可能性があることに注意してください。意図、将来のニーズなどに関するコメントは、あなたのコードを初めて見ている数年後の誰かを助けるのに大いに役立ちます。

私の経験ではそれは異なります。主な要因は、チームがこれらの「小さな」コメントをフォローアップするのに十分な規律があるかどうかです。もしそうなら、彼らは理にかなっています。そうでない場合、これらのコメントは時間の無駄であり、ストーリーカードなどの他のオプションを検討することもできます。

個人的に私は時々TODOコメントを使用しますが、それらは通常短命であり、通常1、2、3のような非常に少数のコメントしかありません。私はそれらを他の何よりもコードベースのマーカーとして使用します。彼らの世話をするのにあまりにも長い間待つと、私は「する」必要があると思ったことを忘れます。

私の好みは常にこれらを使用せず、代わりに適切なストーリーカードまたはバックログなどを使用することです。1つのタスクに1つのメカニズムを使用します。

私は過去にそれらを書いていましたが、通常はフォローアップしないことがわかりました。

そのため、今は忙しいことを終えた直後に作業したいものをマークするためにのみ使用しています。たとえば、新しい関数を実装し、使用している関数に小さなバグがあることに気付きました。私はこれを修正するためにFIXMEを作成し、現在のタスクで脱線を回避します。

私を助けるために、コードにFIXMEがある場合、CIビルドは失敗するようにセットアップされています:-)。

すぐに対処できない潜在的な問題に気付いた場合は、それらのチケット/バグ/問題を開いてください。そうすれば、すべてのバグと同様に優先順位を付けることができます。これは、バグDBにいくつかの問題があり、コードにTODOとして問題があるよりもはるかに優れていると思います。

必要に応じて、バグIDでTODOを入力できます:-)。

TODOコメントはある程度意味があると思います。特に、アジャイルやTDDショップで一般的に行われているように、繰り返し作業している場合、やがて必要になると認識しているものの、その場で実装するための迂回路を作りたくないものがあります。

commentsいのは、そのようなコメントがコードベースに残っているときです。機能に積極的に取り組んでいる間、それらを残しても構いませんが、機能の完成に近づいたらすぐに、それらを取り除くことに集中する必要があります。実際に適切な動作コードに置き換える作業を行わない場合は、少なくとも関連する機能を除外します。@JoonasPulakkaの例を借りるには

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

あなたはそれを次のようなものに変えるかもしれません

ConnManager.getConnection(GetDatabaseName());

とりあえず、GetDatabaseName（）は、最初に使用したのと同じ文字列を単に返すスタブです。そうすれば、将来の拡張の明確なポイントがあり、そこで行われた変更はデータベース名が必要な場所に反映されることを知っています。データベース名が多少一般的であっても、保守性が大幅に向上する可能性があります。

個人的には、厳密にはの代わりに独自のキーワードを使用しますTODOが、意図は同じです。再確認が必要になるとわかっていることをマークするためです。また、コードをチェックインする前に、そのキーワードのグローバルソースコード検索を実行します。これは、通常、コードのどこにも表示されないように選択されています。見つかった場合、私は何かを忘れてしまったことを知っており、先に進んで修正することができます。

プログラマーの名前/署名をコメントに含めることに関しては、ソースコードのバージョン管理システムがある場合はやり過ぎだと思います（そうしますか？）。その場合、その非難機能により、コメントを追加した人、より正確にはコメントに触れた変更を最後にチェックインした人がわかります。たとえば、Visual Studioでは、ソース管理機能の中にある「注釈」機能を使用してこれを簡単に実現できます。

他の誰かが不確定な将来にそのコードに来たときにそれを修正するという考えでTODOまたはFIXMEを書くなら、私は気にしないと言います。コードを散らかし、この情報を収集するIDEのレポート部分を混乱させます。

有用であるためには、適切な心の状態にすばやく戻ることができるように、（非常に）近い将来のためにコードをブックマークする手段を提供する必要があります。つまり、できるだけ早くそれらを削除するためだけにコードに配置します。

実際、長生きするものはすべて、それが属するバグベースに配置する必要があります。

私たちの生活には十分なノイズがあります。他の場所で必要とされる一方で、注意を呼びかけるものの新しいファンファーレを作成しないでください。

私の2セント

通常、私は// TODOコメントを作成しませんが、それらをすべて別のファイルに保存します。それでも、オンラインソフトウェアを簡単に見つけて管理できないので、TODOファイルは私にとって最も便利です。短時間でもプロジェクトを開くと、今何をすべきか忘れてしまい、TODOファイルを調べて仕事をするからです。 。「filename.cpp 354：このbla bla blaを再コード化」しているので、ファイル内で// TODOコメントを検索する方がはるかに便利です。私は怠けたときに// TODOを実行しましたが、ソースファイルからそれらの古い// TODO-sを削除するだけで、プロジェクトが正常に機能する場合は修正しません。すべての// TODOをソースから別の場所に移動し、他のTODOと一緒に保管して、タスクを簡単に優先できるようにすることを強くお勧めします。さまざまなファイルやさまざまなプロジェクトですべてのTODOを取得した場合、優先順位は非常に難しいものです。

そこは素晴らしいと思いますが、一人ではありません。例えば：

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

このアプローチは、かなりうまく機能します。例外をスローする習慣を付けて、いくつかのコードを完了するように思い出させることは、実際には最もプロフェッショナルなアプローチではない、と言わざるを得ません。しかし、あなたが何かを完了したと思う場合や、完了していないときに完了したことを書き留める場合もあります。

Todoコメントが他の何百万ものタスクリストよりも優れていることの大きな利点は、ToDoコメントがコードとともに移動するため、分離できないことです。

おそらく、このようなもののより適切な場所は、コードではなく問題トラッカーです。

すべてのTODOまたはFIXMEを正式なログに入力することを強くお勧めします。そうでない場合、それらは簡単に検索可能であり、未処理のTODOおよびFIXMEをチェックする各反復のフェーズである必要があります。その後、これらをカタログ化し、すぐに修正するように設定するか、チームが適切なタイミングで修正する計画を立てることができます。

最後に、一度修正したら削除する必要があります-解決後に体系的に削除しないと、効果が失われます。

結論：問題をまったく記録しないよりも優れていますが、実際にはそれらを維持する必要があります。

IntelliJは、新しいTODOを含むコードをコミットしようとすると、実際に警告します。そのため、TODOはいつでも「これは本当にコミットするまでに起こるはずです」と解釈できます。

「TODO」をコメントのセマンティックラベルとして考えると、意味があると思います。

私の会社のコーディング標準では、責任のある開発者のイニシャルをTODOに含める必要があると指定しています（つまり、「SAA TODO：」と入力します）。少なくとも慣例として、これは便利だと思います。そうしないと、将来の開発者が対処するために、TODOノートに標準以下のコードを残す誘惑があるからです。

助けになることは、これらのコメントをタスクリストに追加するように多くのIDEを構成できることです。これらのコメントを同様に処理して、無期限に忘れないようにできます。

もっと不愉快でありながら効果的な方法は、おそらくあなたのtodoコメントをコンパイラメッセージに変換することです。そうすれば、あなたや他の人はプログラムがコンパイルされたときにそれを見ることができます。

Delphiの場合：

{$message 'todo: free this thing when you know its not going to blow up'}

私の経験でTODOは、コードの一部が使用できないことを示し、それを使用可能にするために必要なものをローカルまたは他の場所で読者に伝えるために使用する必要があります。

TODO何らかの方法で修正された場合、コードの一部がより優れていることを示すために注釈を使用しないでください。例には、書き直した場合により保守しやすいダーティコードや、まだ誰も必要としない追加機能が含まれます。これらの注釈は積み重なる傾向があり、grep TODO無意味な結果を返します。