2009-10-31 4 views

答えて

7

確かに3人目のスタイル。

20

私は、多くの場合、医師のスタイルを話す傾向がある:

// Now we take $x and check whether it's valid for this pass 
4

役立つTipsを:できるだけ自己完結型として各コメントを維持しようとします。たとえば、このフォーム:

// First, mumble the frabbitz. 

blah blah 

// Second, foobar the quux 

blah blah 

これは素敵な物語ですが、「第一」および「第二」の部分が間違っになる可能性があるので、それは難しいコードを編集することができます。結局のところ、彼らはコメントにそれほど多くを追加するのではなく、それらを壊れやすい方法で相互関係させる。

1

私は時々この

/* 
Usage: 
set_position(0.5, 0.5); // im in the center 
set_position(0.0, 1.0); // im in the lower,left corner 
*/ 
0

ようですが、コードを編集し、どのような目的のためにされているどのように多くの人に依存してもよい、第一の人に話します。それにもかかわらず私自身のコードでは、おそらく「私」を使っていくつかの個人的なコメントを自由に追加することができます。共同プロジェクトでは、コメントは共同体的なスタイルを目指すべきであり、「私」は不在である可能性がある。

コメントは脆弱であり、現代の多くの当局(たとえば、コードのクリーン)は、機能やフィールドに意味のある名前を付ける必要があることに注意してください。しかし、言うまでもなく、説明的コメントが依然として重要な場所はたくさんあります。

3

私の見解では、あなたが最も快適に感じるスタイルを使用してください。

埋め込みコメントは、あなたとあなたのコードの実装の詳細を理解しようとする他の開発者が読むことを前提としています。彼らが明確かつ分かりやすい限り、スタイルが少し珍しい、文法が少し悪い、またはいくつかのスペルミスがあるかどうかは重要です。それを読んでいる人々は、そのようなことを気にすること以上にすべきである。

APIドキュメントを作成するために抽出されたコメントは、スタイル、文法、スペルの細部に少し注意を払う必要があります。しかし、ここでも精度と完全性ははるかに重要です。

+2

コメントに関するコメントに同意する必要があります。私にとって、読みやすいコメントはよく書かれたものです。これは良い文法、良いスペル、良い句読点を意味します。 –

+0

ねえ、見て、私はまた、コメントに悪い文法のスペル等を見て苛立つことがわかります。しかし、私はこれを苦情なしに言い張ります。非常に少数の開発者が散発的な散文を作成する能力があります。たとえそうであったとしても、彼らの発言を磨くよりも、時間をかけてやることができるより生産的なことがあります。 –

関連する問題