他の人のコードを見て、彼らのコメントスタイルを見るのが大好きです。ほとんどの人は*と////の組み合わせを使用します。言語にもよりますが、私は間違いなくいくつかの良い方法といくつかの悪い方法を見てきました。コーディングされたページは、実際には適切なコメント構造と一緒になり、誰も知らなくてもプロジェクトに参加した人にとっては本当に読みやすくなります。コメントスタイルギャラリー...あなたのコメントのスタイルを投稿する投稿
私は人々が、コメントやセクション区切りなどのスタイルを設定する最良の方法だと思っているのを知りたいのです。これはhtml、php、またはその他のもののためのものです。
PHP：
は個人的に私は、メソッド/関数の内部ですべてのため//を使用しています。誰かが/* */を使用すると迷惑になります。なぜなら、コードブロックをコメントにすることが難しくなるからです。
私は、phpdocがjavadocによく似たものを使用しています。
15-20行のコメントがない場合は、コードが本当に自明でない限り、コメントを入力する必要があります。あなたはあなたの500ライン機能とそれをすべて覚えていると思うかもしれませんが、しばしば時間はありません。それが誰かに入ってあなたのコードを理解しようとしているなら、それはもっと難しいでしょう！
側ノード（クイックリンク、ない鉱山）：http://www.heartysoft.com/ninja-coding-code-comments
なぜ私がコメント
が好きではありません私は自分のコードをコメント避けるためにしようとしている主な理由は概念であり、自明コードの コードは自己説明的でなければなりません - コードを読む 誰もが何が起こっているのかを理解する必要があります（ドメインの知識があれば）。 に何が起こっているのかを説明するコメントにはまったく適していません。コードは、 のコメントが更新されるよりもはるかに頻繁に変更される予定です。あなたのチームがどれほど警戒していても、これは実現するためには です。せいぜい、これは若干古くなった コメントにつながる可能性があります。最悪の場合、古くなったコメントは、コードが実際に何をしているのか全く誤解を招く可能性があります。
-
私はいつもそれが任意の追加の説明を必要としないように、私のコードをリファクタリングしようとしています。
私は結局、APIDocを自動生成するための通常のxDocコメント以上を持つことに終わります。これらのコメントでさえ、大部分が自動生成されます。
問題（OS固有の問題など）では、問題を議論してリンクを追加しようとします。リンクが将来の時間内に壊れた場合 - たわごとが発生します。
-
AS3：単一行のコメントの
//
：私はこれを使用しながら、
/**
*
* to comment (if necessary) a method or a group of related methods
*
*/
：AS3で
/**
* This is a usual doc comment for a type or property.
*/
/*
* This is a marker of a particular longer section of code.
*/
// This is a single line comment before a or at end of a line of code.
、私はこれを使用しています。
さらに、私は通常、空きのコード//を挿入してコードの再生産性をもう少し向上させます。
私の場合は、必要に応じてブロックコメントとドキュメント処理 - jsdocの両方に同じです。 – danjah