評論相對於代碼的位置

在您的代碼中放置評論的最佳方式是什麼？我看到至少有三種不同的方式：評論相對於代碼的位置

1: 
int i = 10;  //Set i to 10 

2: 
//Set i to 10 
int i = 10; 

3: 
int i = 10; 
//Set i to 10

使用第一種方法的缺點是，許多人使用的標籤，而不是空格，這樣做將導致評論成爲選項卡大小變化時嚴重錯位。

第二個和第三個代碼片段可以避免這個問題，但是當有很多代碼時，它有時不清楚評論所指的是哪一行。

來源

2010-01-26 gamedevv

火焰戰爭等待發生。 – danben 2010-01-26 00:21:40

「使用第一種方法的缺點是很多人使用製表符而不是空格」：很好 - 現在我們可以將評論性宗教大戰與製表符結合起來v。在一個SO主題中捆綁宗教戰爭。 – 2010-01-26 00:23:16

使用製表符間隔是錯誤的。 – cletus 2010-01-26 00:24:52

選項3只是錯誤的。我所知道的所有工具都希望方法文檔在2之前的方法中出現。因此，在方法內部做相反的處理是令人困惑的。

否則，1 & 2都可以，但我只能在短代碼行上使用1。一般來說，2將是我的首選選項，因爲它不僅符合方法/類的註釋約定，您可以在之前的代碼中看到註釋。

來源

2010-01-26 00:24:19

那麼，這種形式應該只有很少的評論 - 如果你發現自己評論個別陳述，有些事情是錯誤的。話雖如此，我沒有＃1或＃2的問題 - 我從未見過＃3，也不想。

來源

2010-01-26 00:23:19

方法中的註釋沒有任何問題。如果您正在實施算法，則評論可以描述算法步驟。 – 2010-01-26 00:25:42

這就是你的代碼所做的或者應該做的。 – 2010-01-26 00:27:21

代碼可以告訴你正在採取的步驟，但它不能告訴你爲什麼他們被採取。 – danben 2010-01-26 00:32:43

我主要是爲了上面的 - 在註釋上方有一個空行，所以它明確指代下面的代碼而不是別的。

有幾次我去找下一個 - 比如記錄變量聲明等等。

來源

2010-01-26 00:24:25

首先嚐試編寫代碼，以便「自行評論」。我的意思是在大多數情況下，如果其他開發人員查看您的代碼，並且不明白它是什麼，那麼95％需要重構。

如果不能，你應該使用選項2號，因爲它有助於保持shors行代碼編輯器

來源

2010-01-26 00:24:50

我要說的是，你應該使用1:單行註釋，即當你想先解釋一下在單行上不明顯，並且如果行足夠短以便評論適合所以行不超過80個字符，那麼2:應該沒問題。

使用2:意見徵求更長的塊，即試圖解釋算法或解碼等

不要使用3:可言。

來源

2010-01-26 00:24:55 epatel

我建議閱讀第32章：在Code Complete中自行編寫代碼。

它有很多關於如何以及在何處發表評論的深思熟慮的建議。

來源

2010-01-26 00:25:00 Ruddy

我喜歡下面的表格簡稱意見

blah; // comment

兩個空格前不知何故//目光吸引我。更長的評論在我看來在塊之前。

來源

2010-01-26 00:26:41 Anycorn

我個人更喜歡選項。如果評論足夠短並提供一些必要的信息，則選項是可以的。

評論應該做的更少，以解釋明確情況下的代碼是什麼，以及更多解釋原因。

來源

2010-01-26 00:26:57 jschmier

我使用某種類型的Javadoc（顯然）：

/** 
* This is a Javadoc comment. 
*/

和我一起去結合一個襯墊用空格內碼：

// This comment refers to 
someGroupingOfCode(); 
thatPerforms(aCertainTask); 
whichIsThenFollowedBy(anEmptyLine); 

// And possibly another comment 
thatGoesWith(); 
theNextGroupOfTasks();

而對於聲明我一般做：

int i; // This stores the value of your eye 
File x; // XXX directory location

至於我是否使用最後一個例子中的標籤，我甚至不會去那裏。現在不想把汽油扔在火上。 :)

來源

2010-01-26 00:40:19 Jeff

評論相對於代碼的位置

回答

相關問題