如何評論if-else結構？

Question

比方說你有：

if(condition) { 
    i = 1; 
} else { 
    i = 2; 
} 

，你需要把註釋解釋if和else塊。做這件事最可讀的方式是什麼，所以有人可以很容易地撿起它們？

我通常不喜歡這樣：

//check for condition 
if(condition) { 
    i = 1; 
} else { 
    //condition isn't met 
    i = 2; 
} 

，我覺得不夠好意見分別位於不同的層次，所以在快速瀏覽你只需拿起if評論和else評論看起來像它屬於某種內部結構。

把他們像這樣：

if(condition) { 
    //check for condition 
    i = 1; 
} else { 
    //condition isn't met 
    i = 2; 
} 

不好看我要麼因爲它會像整個結構沒有被註釋掉（條件可能是大的，並採取多線）。

類似的東西：

//check for condition 
if(condition) { 
    i = 1; 
//condition isn't met 
} else { 
    i = 2; 
} 

將可能從查看評論點最好的風格，但令人困惑的代碼結構。

你如何評論這樣的塊？

PS。我不是在重構這兩行代碼，只關注代碼樣式和註釋格式。

Answer 1

我不會在這些特殊情況下發表評論 - 評論不會爲您已經清晰的代碼增加任何價值。如果你有一個非常複雜的條件難以閱讀，我會考慮把它分解成一個函數（可能是inline），它的名字很乾淨。

Answer 2

如果代碼不是自我解釋的，那麼只應該註釋。所以讓自我解釋。像這樣也許

bool fooIsNotReallyGood = ....; 

if(fooIsNotReallyGood) { 
... 
} else { 
... 
} 

Answer 3

//condition isn't met似乎是一個無用的註釋。但是，在需要這樣的評論的情況下，我不喜歡這樣（C＃）：

//check for condition 
if(condition) 
{ 
    i = 1; 
} 
//some other condition 
else 
{ 
    i = 2; 
} 

然而，如果該塊正好的if-else，比我之前如果合併雙方的意見。

對於JavaScript我喜歡

//check for condition 
if(condition) { 
    i = 1; 
} else { //some other condition 
    i = 2; 
} 

附：似乎有許多意見，還有人:)

Answer 4

您可以提取if-else代碼的方法和正確命名它們：

function main() { 
    checkForCondition(condition); 
    conditionIsNotMet(condition); 
} 

function checkForCondition(boolean condition) { 
    if (condition) { 
    i = 1; 
    } 
} 

function conditionIsNotMet(boolean condition) { 
    if (!condition) { 
    i = 2; 
    } 
} 

在這似乎是一個矯枉過正這樣一個小例子，但是想象一下，有更多的比每if-else分支一行。

Answer 5

另一種選擇是：

if(condition) { //check for condition 
    i = 1; 
} else { //condition isn't met 
    i = 2; 
} 

Answer 6

的變量是重要的，而不是條件本身。

if condition: # <condition dependent variable> was <predicated> 
    dosomething() 
elif othercondition: # <othercondition dependent variable> <predicated> 
    dootherthing() 
else: # <all variables> <not predicated> 
    doelsething() 

Answer 7

這是我如何做我的意見，如果然後語句，雖然我通常發現它並不需要。我喜歡把它與if/else一致，並且選項卡在相同的地方

if (condition) //if above the bar 
{ 
    i = 0; 
    k = 1; 
} 
else    //else if below 
{ 
    i = 1; 
    k = 2; 
} 

Answer 8

查看自我評論條件，則不需要額外註釋。假設條件是達到了最大的貸款價值。這給了我們：

if (maximumLoanToValueIsReached) 
{ 
    i=1; 
} 
else 
{ 
    i=2; 
} 

無需指定i = 2時，最大的貸款價值還沒有達到，因爲這是自explanitory。另外，我還會將i重命名爲更有意義的內容。

Answer 9

如果需要評論else語句，我更願意描述使代碼達到那個點的情況。 特別是在高圈複雜

if (condition) { 
// User is taking a course at college x: 
    i = 1; 
} else { 
// User is not taking any course at college x: 
    i = 2; 
} 

Answer 10

沒有單一的答案代碼 - 不同的人就會有什麼是最可讀不同意見。然而，我認爲，評論應該實際上爲（不言自明的）代碼增加價值並且評論風格應該一致。

我處理不立即不言自明的條件意見的方式是這樣的：

// If the condition for a local tree imbalance is met, 
    // juggle the immediate nodes to re-establish the balance. 
    // Otherwise, execute a global balancing pass. 
    if (somewhat muddled condition) 
    { 
    ...code... 
    } 
    else // Tree is in local balance 
    { 
    ... more code... 

    } // if/else (tree locally imbalanced) 

最終「}」註釋的存在主要是給的條件更視覺重量的結束，使通過源閱讀更容易。

Answer 11

如果代碼是沒有自我記錄，那麼我將如下構建它：

if (someCondition) { 
    // If some condition, then do stuff 1. 
    doStuff1(); 
} 
else { 
    // Else do stuff 2. 
    doStuff2(); 
} 

但同樣，它並沒有多大意義，如果代碼已經是自文檔。如果你想補充的，因爲像一些複雜條件評論：

if (x == null || x.startsWith("foo") || x.endsWith("bar") || x.equals("baz")) { 
    doStuff1(); 
} 
else { 
    doStuff2(); 
} 

然後我會考慮重構它爲：

boolean someCondition = (x == null || x.startsWith("foo") || x.endsWith("baz") || x.equals("waa"); 

if (someCondition) { 
    doStuff1(); 
} else { 
    doStuff2(); 
} 

其中的變量名someCondition實際上總結整個狀態簡而言之。例如。 usernameIsValid，userIsAllowedToLogin左右。

Answer 12

評論是非常個人的事情，並且（從一些早期的答案中可以看出）引起了與代碼一樣多的爭論。

在簡單情況下，評論會減損代碼。但假設一個更復雜的條件，我更喜歡：

/* 
** Comment explaining what the condition 
** is trying to determine 
*/ 
if (condition) 
{ 
    /* 
    ** Comment explaining the implications 
    ** of the condition being met 
    */ 
    do_something(); 
} 
else 
{ 
    /* 
    ** Comment explaining the implications 
    ** of the condition not being met 
    */ 
    do_something_else(); 
} 

在任何情況下，評論不能只是重複代碼。