タグ付けされた質問 「comments」

バグの修正/ CRの実装の一環としてコードに加えた変更ごとに、開始タグ、終了タグ、説明、解決策などのコメントを追加するよう求められています。 私の懸念は、これが付加価値を提供するかどうかです。現状では、バージョン管理履歴にすべての詳細があります。これは、すべての変更を追跡するのに役立ちますか？ しかし、私のリードは、コメントを「良い」プログラミング手法として主張しています。彼らの議論の1つは、CRのスコープを変更/変更する必要がある場合、コメントがないと面倒になることです。 変更は主にコードの中間にあると考えると、私たちが行うすべての変更にコメントを追加することは本当に役立つでしょうか？バージョン管理に任せてはいけませんか？

42 version-control  bug  comments  change 

ヘッダーコメント内のファイル自体にバグ番号を入れるのは良い習慣ですか？ コメントは次のようになります。 MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description 役立つように思えますが、それは悪い習慣と見なされていますか？

40 version-control  development-process  source-code  comments 

「コメントは時代遅れになりがちだ」と​​いう主張をする人は常にいます。事は、私は私のキャリア全体で2つまたは3つの時代遅れのコメントを見たことがあると思います。別々のドキュメントの古い情報は常に発生しますが、私の経験では、コード自体の古いコメントは非常にまれです。 誰と仕事をしているのか幸運だったのですか？特定の産業は他の産業よりもこの問題を起こしやすいですか？あなたはありますか特定のあなたが見てきた最近の時代遅れのコメントの例は？それとも、時代遅れのコメントは実際の問題よりも理論的な問題ですか？

38 comments  myth 

プログラミングの過程を通じて、コードを説明するコメントと、コードを削除するコメントがいくつかあります。 // A concise description const a = Boolean(obj); //b = false; どちらをすばやく解析する良い方法はありますか？ 私は3使って周りにプレイした/のをと/** */説明コメントのために。 また、VSCodeプラグインを使用して強調表示し//TODO:、//FIXME:

38 javascript  comments 

コメントが適用される行に収まらない（または行けない）と仮定した場合、コードの前または後にコメントを書く必要がありますか？ さて、将来の読者がコメントの範囲を最もよく理解するところはどこでも。言い換えれば、ほとんどのプログラマー/スクリプト作成者がそのようなコメントを書くところです。 では、ほとんどのプログラマー/スクリプト作成者は、コードの前後にどこにコメントを入れますか？ 回答が特定の言語のみに適用される場合は、どちらを指定してください。 そして、あなたの答えをサポートする受け入れられた仕様またはガイドを引用できるなら、それははるかに良いです。

34 comments 

プログラミング言語とマークアップでは、コメントは一般にどのように扱われますか？私はいくつかのカスタムマークアップ言語のパーサーを書いており、最も驚きの少ない原則に従うことを望んでいるので、一般的な規則を決定しようとしています。 たとえば、トークン内に埋め込まれたコメントは、トークンと「干渉」する必要がありますか？一般的に、次のようなものです： Sys/* comment */tem.out.println() 有効ですか？ また、言語が改行に敏感であり、コメントが改行にまたがっている場合、改行を考慮するかどうか stuff stuff /* this is comment this is still comment */more stuff として扱われる stuff stuff more stuff または stuff stuff more stuff ？ 私はいくつかの特定の言語が何をするかを知っており、意見を求めていませんが、トークンと新しい行に関してマークアップによって一般的に期待される一般的なコンセンサスはありますか？ 私の特定のコンテキストは、Wikiのようなマークアップです。

31 parsing  comments 

開発者の発芽を目的とした、コードコメントの作成に関する決定的なガイドはありますか？ 理想的には、コメントをいつ使用するべきか（使用すべきではない）、およびコメントに何を含めるべきかについて説明します。 この答え： 何をしているのかをコメントしないでください。 WHATは、それをサポートする変数名を適切に選択した、クリーンで読みやすいシンプルなコードによって処理されます。コメントは、コード自体では表示できない（または表示が難しい）コードの上位レベルの構造を示します。 近づきますが、経験の浅いプログラマーにとっては少し簡潔です（いくつかの例とコーナーケースでの拡張は素晴らしいと思います）。 更新：ここでの回答に加えて、別の質問に対するこの回答は非常に関連性が高いと思います。

27 language-agnostic  comments 

私が見た、これはSO居酒屋に尋ねたので、私はここに質問を投稿しています。面白い質問だと思いました。（もちろん、SOに属していませんが、ここでは問題ないと思います。） コードコメントにピリオドを追加しますか（またはOPが書いたように「フルストップ」）。 関連性を保つために、なぜですか？

27 source-code  comments  coding-style  grammar 

コードにコメントを書く際のアドバイスや経験をお聞かせください。それらを最も簡単で有益な方法でどのように書くのですか？コードの一部をコメントするとき、どのような習慣がありますか？たぶん、いくつかのエキゾチックな勧告？ この質問が、コメントのための最も興味深いアドバイスと推奨事項を収集することを願っています。 OK、始めます。 通常、/* */多くの行をコメントする必要がある場合でも、コメントは使用しません。 利点：このような構文と1行のコメントを混在させるよりも、コードの見た目が良くなります。ほとんどのIDEには、選択したテキストをコメントする機能があり、通常は1行の構文でコメントします。 短所：IDEなしでこのようなコードを編集するのは難しいです。 完成したコメントの最後に「ドット」を置きます。 例えば： //Recognize wallpaper style. Here I wanted to add additional details int style = int.Parse(styleValue); //Apply style to image. Apply(style); 利点：完了したコメントにのみ「ドット」を配置します。一時的な情報を書き込むことができる場合があるため、「ドット」がないと、戻り、このコメントにテキストを追加する必要があることがわかります。 列挙内のテキストの位置合わせ、コメントパラメーターなど 例えば： public enum WallpaperStyle { Fill = 100, //WallpaperStyle = "10"; TileWallpaper = "0". SizeToFit = 60, //WallpaperStyle = "6"; …

26 coding-style  comments 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 関数型プログラミングを始めたばかりで、コードをコメントする正しい方法について疑問に思っています。 名前と署名はすでにあなたが知る必要があるすべてをあなたに伝えるはずなので、短い関数をコメントすることは少し冗長に思えます。大きな関数は一般的に小さな自己記述関数で構成されているため、大きな関数のコメントも少し冗長に見えます。 機能的なプログラムにコメントする正しい方法は何ですか？反復プログラミングと同じアプローチを使用する必要がありますか？

25 functional-programming  comments 

1つの言語だけでなく、コメントをネストできないように見えます。この問題の良い解決策はありますか？C / C ++およびJavaでの1つの回避策は、単一行コメントのみを使用することですが、より大きなブロックをコメントアウトすることは不可能になります。私はこのようなものに直面しています： </li><!-- <li><!-- Save --> そのため、コメントを手動で確認して編集する必要があります。多くの言語でこれをどのように扱うべきかアドバイスをいただけますか？私にはわからないが、多分、Pythonにコメント'''を含めることができるかもしれない方法でこれを解決できるの#でしょうか？`

23 java  c++  python  c  comments 

ロックされています。この質問に対するコメントは無効になっていますが、新しい回答やその他の相互作用はまだ受け付けています。詳細をご覧ください。 検索しましたが、探しているものが見つかりませんでした。この質問が既に質問されている場合は、お気軽にリンクしてください。 今月初めにこの投稿が行われました： http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/ 基本的には、コメントを書かないと悪いプログラマーになります。私の意見では、コードは記述的であり、コードが自己記述的でない場合を除き、ほとんどコメントを必要としないはずです。 与えられた例では // Get the extension off the image filename $pieces = explode('.', $image_name); $extension = array_pop($pieces); 著者は、このコードにはコメントを付けるべきだと述べました。私の個人的な意見では、コードは記述的な関数呼び出しである必要があります。 $extension = GetFileExtension($image_filename); しかし、コメントでは誰かが実際にその提案をしました： http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/comment-page-2/#comment-357130 著者は、コメンターは「それらの人々の1人」、すなわち、悪いプログラマーであると答えました。 自己記述型コードとコメント型コードについて、他の誰もが見ていることは何ですか？

22 coding-standards  comments 

コードの大部分を変更する必要があることがわかったときは、それが間違っているか、他の理由で必要となる主要なアーキテクチャの変更に適応する必要があるため、これは私が通常行うことです： 変更が必要と思われるすべてのコードをコメント化します。コメントアウトされたコードは、TODOリストの一種として扱います。 コメントアウトされたコードを徐々に確認し、このコードの一部のコメントを外すか、必要に応じてコピーアンドペーストして必要に応じて編集するか、このコードの一部を最初から書き直して、コメントアウトされたコードを参照します。コメントアウトされたコードの一部が完了したと思うたびに、それを削除します。 コードがコメントアウトされなくなるまでこれを続けます。 私は主に、私が単独で開発している個人プロジェクトでこれを行っていることに注意する必要があります。 しかし、私はこれをやめるべきだと言われました。代わりに、コメントアウトされたコードを残すのではなく、古いコードを見るために古いコミットを参照してgitを使い始めるべきだと言われました。私が言われた： コードをコメントアウトするのは悪い習慣であり、一掃する必要があります。経験がないため、それを理解できません。数年後に、コードをコメントアウトするのが好きな別の人のコードを見つけた場合、自分でこの人を非難するでしょう。コメントアウトされたコードを見るたびに、私はそれを見ずにその全体を削除します。通常、そのようなコードは完全に価値がないからです。小規模な個人プロジェクトでは、コードをコメントアウトすることのマイナス面を確実に見落とすでしょう。しかし、あなたが仕事を見つけて、この習慣をそこに保つならば、それは残念です。 私が今見逃していることの、私がやっていることのこれらの欠点は何ですか？ 私は、過去のコードを見るためにgitを使用することだけに熱心ではないと言わなければなりません。私が言ったように、私はコードをコメントアウトすることを一種のtodoリストとして扱います。gitは、コードが以前どのように表示されていたかを示しますが、コードのどの部分がまだレビューが必要で、どの部分がすでに実行されているかを明確に示すことはできません。コードの一部を見逃し、バグを導入する恐れがあります。 完全を期すために、引用している人は経験豊富な開発者であり、ボブおじさんの「クリーンコード」のファンであると付け加えるべきだと思います。

21 anti-patterns  comments 

この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 7年前に移行され ました。 最近のコメントはこれまで以上に簡単です。Javaには、コメントをクラスにリンクするための優れた手法がいくつかあり、Java IDEはコメントシェルの作成に適しています。Clojureなどの言語では、関数のコード自体に関数の説明を引数として追加することもできます。 しかし、私たちは今でも良い開発者によって書かれた時代遅れのコメントや劣悪なコメントが頻繁にある時代に生きています。 特にここではJava / Clojure / Pythonに興味がありますが、回答は言語固有である必要はありません。 コメントを検証し、「薄っぺらな」コメント（マジックナンバー、不完全な文などのコメントなど）または不正なコメント（スペルミスなどの検出など）を自動的に検出する新しい手法はありますか。 そしてもっと重要なことは、「コメント政策」や戦略が受け入れられているということですか？コーディング方法に関するアドバイスはたくさんありますが、「コメントの方法」についてはどうでしょうか。

20 java  python  clojure  comments 

いくつかのオープンソースプロジェクトから、次のコーディングスタイルを集めました void someFunction(bool forget); void ourFunction() { someFunction(false /* forget */); } falseここで何を意味するのか、私はいつも疑っています。それは「忘れる」ことを意味しますか、それとも「忘れる」は対応するパラメーターを参照しますか（上記の場合のように）、「false」はそれを無効にすることを意味しますか？ どのスタイルが最も頻繁に使用され、曖昧さを避けるための最良の方法（またはいくつかのより良い方法）は何ですか？

19 coding-style  comments  boolean