Как следует прокомментировать структуру if-else?

Допустим, у вас есть:

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. Я не спрашиваю о рефакторинге этих двух строк кода, а только о стиле кода и форматировании комментариев.


person Community    schedule 13.04.2010    source источник
comment
Со всем этим текстом вопрос совсем не быстрый :-)   -  person Nathan Fellman    schedule 13.04.2010
comment
Спасибо, что задали этот вопрос, меня тоже всегда интересовало.   -  person helpermethod    schedule 13.04.2010
comment
Я думаю, что это следует снова открыть - это вопрос о стиле кодирования, на который можно ответить, основываясь на опыте.   -  person Cookie    schedule 11.04.2014


Ответы (12)


Если необходимо прокомментировать операторы if 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;
}
person Community    schedule 13.04.2010
comment
Мне это нравится ... особенно комментарий в блоке else. Ваше условие должно быть ясным, но в зависимости от длины и сложности (особенно вложенности) кода значение else может быть совсем неочевидным. - person mmc; 21.08.2012
comment
Это не сработает, если, например, вы захотите добавить комментарий для i = 2 внутри блока else. Похоже, что оба они предназначены для i = 2 или оба предназначены для блока else. - person aandis; 03.05.2015
comment
@aandis Вы можете сделать отступ в комментарии, относящемся к i = 2;, чтобы различать. Хотя я думаю, что в любой реальной ситуации сам комментарий не должен оставлять сомнений в том, относится ли он к условию или первому утверждению. - person Daniel Saner; 06.07.2018
comment
@aandis Или в этом случае вы можете поместить два комментария, разделенных одной строкой. Вертикальное пространство не должно быть проблемой, поскольку длинные или нечеткие методы следует преобразовать в более мелкие / более четкие. - person Guimo; 30.04.2019

Другой вариант:

if(condition) { //check for condition
    i = 1;
} else { //condition isn't met
    i = 2;
}
person Community    schedule 13.04.2010
comment
это вариант, который мне нравится ... если комментарии не очень длинные, тогда вы облажались ... Я расстраиваюсь и удаляю комментарии, потому что они выглядят некрасиво. - person mpen; 13.04.2010
comment
+1 Лучшее решение на мой взгляд. - person helpermethod; 13.04.2010
comment
Вот что я делаю. Если комментарии длинные, поместите блок комментариев над условным объяснением всего этого. - person drawnonward; 13.04.2010
comment
Мне нравится, что все комментарии начинаются с одной и той же позиции (желательно на верхнем уровне). Мне труднее читать, когда они повсюду. - person serg; 13.04.2010
comment
Для меня проверка на условие бесполезна ни сама по себе, ни как общий заполнитель. Комментарии ДОЛЖНЫ быть полезными, а не просто повторять код, поэтому я предпочитаю (подробно описано ниже) комментариев, объясняющих, что условие пытается определить. - person Andrew; 09.09.2012

Аннотировать следует только в том случае, если код не требует пояснений. Так что сделайте если понятным. Как это возможно

bool fooIsNotReallyGood = ....;

if(fooIsNotReallyGood) {
...
} else {
...
}
person Community    schedule 13.04.2010
comment
+1 Я стараюсь, чтобы мой код был понятен без комментариев - person David Johnstone; 13.04.2010
comment
Спасибо, но вопрос не в этом. - person serg; 13.04.2010
comment
@ serg555: Вы не можете явно задавать этот вопрос, но это все равно ответ. Если бы вы использовали реальные комментарии в приведенных выше примерах, сразу стало бы ясно, что это полностью зависит от того, к чему относится конкретный комментарий. Фактический комментарий на внешнем уровне, например, может объяснить, что, когда у вас установлена ​​определенная видеокарта, возникает ошибка, которая в противном случае не является проблемой, поэтому вы делаете что-то по-другому в зависимости от этого условия. Внутренний комментарий может объяснить особенно сложный алгоритм и то, как он связан с этой конкретной ветвью оператора if. - person Mike Burton; 14.04.2010
comment
Это нормально в идеальном мире простого кода. Однако, если первый блок длинный, может быть уже не так ясно, на что ссылается блок else (также в случае вложенных if). Он также может очищать чужой код, который не хотел бы проводить рефакторингом. Совершенно законный вопрос. - person mmc; 21.08.2012
comment
@mmc - вот что я добавил переменную bool. Все тесты можно свести к одной переменной. Если вам нужно несколько переменных, чтобы уменьшить тест, чтобы улучшить читаемость и тому подобное. Это работает во всех случаях. Если вы считаете, что какой-то код слишком сложен, вы должны иметь возможность создать простое выражение, и это нужно сделать только один раз, чтобы будущие читатели могли увидеть, как работает тест. Также я не могу представить ни одного фрагмента кода, в котором нельзя было бы упростить код. Если упрощение приводит к проблемам с производительностью - это когда вы вводите сложный код с обильными комментариями. - person Preet Sangha; 22.08.2012
comment
Это полезный метод, но он определенно не устраняет необходимость в комментариях if / else во всех ситуациях. - person Jonathan Potter; 24.04.2015

Если код еще не самодокументируется, я бы структурировал его следующим образом:

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 или около того.

person Community    schedule 13.04.2010
comment
Я также предпочитаю комментировать выше на том же уровне вкладки. Я не согласен с тем, чтобы не комментировать код, оператор if может быть простым как someCondition, но внутри его структуры есть, например, 300 строк, и в этом случае НЕ комментировать оператор else было бы глупо, потому что вам нужно прокрутить 300 строк вверх, а другой 300 дно .. - person s3m3n; 20.04.2013

Используйте условия для самостоятельного комментирования, тогда в дополнительных комментариях нет необходимости. Допустим, условием является достижение максимальной стоимости кредита. Это дает нам:

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

Нет необходимости указывать, когда i = 2, что максимальная сумма кредита не была достигнута, поскольку это не требует пояснений. Кроме того, я бы также переименовал i во что-нибудь более значимое.

person Community    schedule 13.04.2010

Комментарии - это очень личное дело, и (как видно из некоторых предыдущих ответов) вызывают столько же споров, как и код.

В простых случаях комментарии отвлекают от кода. Но, предполагая более сложное условие, я предпочитаю:

/*
** 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();
}

В любом случае комментарии не должны просто повторять код.

person Community    schedule 21.08.2012

Я бы вообще не стал комментировать эти конкретные случаи - комментарии не добавляют никакой ценности вашему и без того ясному коду. Если у вас действительно сложное условие, которое трудно прочесть, я бы подумал о том, чтобы преобразовать его в функцию (вероятно inline) с очень понятным собственным именем.

person Community    schedule 13.04.2010

//condition isn't met кажется бесполезным комментарием. Но в случае, когда такой комментарий требуется, я делаю это так (C #):

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

Однако, если блок - это просто if-else, я бы объединил оба комментария перед if.

Для javascript я предпочитаю

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

P.S. Вроде мнений столько, сколько людей :)

person Community    schedule 13.04.2010

Вот как я делаю свои комментарии к операторам if then, хотя обычно считаю, что это не нужно. Мне нравится ставить его в соответствие с if / else и помещать в одно и то же место

if ( condition )    //if above the bar
{
    i = 0;
    k = 1;
}
else                //else if below
{
    i = 1;
    k = 2;
}
person Community    schedule 13.04.2010
comment
Мне нравится этот метод работы. Он может занимать больше места, но дает абсолютно четкое представление о том, что покрывается оператором loop / if. - person Faken; 13.04.2010

Однозначного ответа нет - разные люди будут по-разному относиться к тому, что наиболее читаемо. Однако я думаю, что есть согласие, что комментарии должны фактически добавлять ценность (в противном случае не требующую пояснений) коду и что стиль комментирования должен быть согласованным.

Я обрабатываю комментарии для условий, которые не сразу требуют пояснений, следующим образом:

  // 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) 

Комментарий к заключительному символу "}" предназначен в первую очередь для того, чтобы придать окончанию условия больший визуальный вес и облегчить чтение исходного текста.

person Community    schedule 13.04.2010

Важны переменные, а не сами условия.

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

Вы можете извлечь 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 ветку приходится более одной строки.

person Community    schedule 13.04.2010
comment
Лол, в таком случае не лучше ли сделать что-нибудь подобное? if (условие) conditionIsMet (); иначе conditionIsNotMet (); - person Aoi Karasu; 13.04.2010
comment
С этим кодом много проблем. Во-первых, связь «или / или» между вашими двумя функциями (тот факт, что всегда будет действовать только одна из них) скрыта в main(). Вы должны посмотреть фактические утверждения в нескольких местах и ​​не сразу увидеть, могут ли быть какие-либо побочные эффекты. Вы также дважды проверяете условие, что потенциально дорого. И это добавляет накладные расходы на два вызова функций, которые, вероятно, также захотят вернуть что-то обратно в main. - Я знаю, что ответ старый, но подумал, что не повредит каким-то образом поддержать отрицательные голоса. - person Daniel Saner; 06.07.2018