Вы ставите условный код на новую строку или только иногда? - PullRequest
2 голосов
/ 23 апреля 2009

Обычно я всегда пишу условный код в соответствии с

if (number==1) 
    name="a";
if (number==2)
    name="b";

независимо от того, насколько коротким, хотя я нахожу немало людей, пишущих

if (number==1) name ="a";
if (number==2) name ="b"...

Мне это кажется противоречивым и фактически делает код более запутанным.

Каков наилучший способ сделать это?

Ответы [ 16 ]

17 голосов
/ 23 апреля 2009

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

В любом случае, я фанат обертывания каждого такого состояния тела фигурными скобками; По моему опыту, они делают тело более заметным и снижают риск ошибок, если строки добавляются или опускаются.

8 голосов
/ 23 апреля 2009

Я предпочитаю ваш первый вариант, но еще лучше:

if (number == 1) { 
    name = "a";
}
if (number == 2) {
    name = "b";
}

немного длиннее при простом просмотре, но мне не нужно добавлять скобки, если значение больше одной строки (я думаю, очень часто)

7 голосов
/ 23 апреля 2009

Я всегда пишу свои условия одинаково:

if (number == 1)
{
    name = "a";
}
else if (number == 2)
{
    name = "b";
}

Это легко читается и соответствует. Соответствует операторам if, имеющим более одного оператора и т. Д. *


Редактировать

Чтобы расширить это, я пытаюсь следовать этому правилу:

Каждая строка делает одно.

То есть каждая строка должна выполнять одну инструкцию (и область видимости должна быть легко видимой). Поэтому я не предпочитаю:

if (number==1) name ="a";

Поскольку в одной строке происходят две вещи, что делает чтение и отладку более трудным, чем должно быть. Поэтому я бы перешел к:

if (number==1)
    name ="a";

Но проблема в том, что он несовместим с мульти-оператором if. Вот почему (как уже говорили другие) хорошо ставить скобки вокруг вещей:

if (number==1)
{
    name ="a";
}

Причина, по которой я предпочитаю '{' в отдельной строке, заключается в том, что когда я сканирую код, я могу быстро определить, где начинается и заканчивается область действия. Он также следует правилу одного оператора, поскольку операторы if и {{'делают оператор if и , чтобы начать новую область видимости.

Я не думаю, что "он сохраняет вертикальные пробелы" - это достаточно веская причина, чтобы пропустить удобочитаемость и хорошее форматирование (оба {} в одном столбце == сексуально). Это связано с тем, что, учитывая разрешение современных мониторов, вам не нужно бороться за просмотр кода.

2 голосов
/ 23 апреля 2009

Python в значительной степени заставляет вас, так что да - условный код всегда идет с новой строки.

if number == 1:
    name = "a"
elif number == 2:
    name = "b"
else:
    raise ValueError()
2 голосов
/ 23 апреля 2009

Лично я люблю размещать условные выражения в одной строке, ЕСЛИ И ТОЛЬКО ЕСЛИ, есть набор из них, который я хочу легко сравнить.

if      (iTerm >= Ps.missed_runs)   iTerm -= Ps.missed_runs;
else if (iTerm <= Ps.missed_runs)   iTerm += Ps.missed_runs;
else                                iTerm  = 0;

Здесь я ясно вижу, что то же самое, а что отличается. Сравните с этим:

if (iTerm >= Ps.missed_runs) {
    iTerm -= Ps.missed_runs;
} else if (iTerm >= Ps.missed_runs) {
    iTerm += Ps.missed_runs;
} else {
    iTerm  = 0;
}

Теперь сравнения далеки друг от друга и не выровнены по столбцу. Глазу труднее обнаружить ошибку.

P.S. Вы заметили преднамеренную ошибку во втором примере кода?

Hugo

2 голосов
/ 23 апреля 2009

Я твердо верю, что если вы собираетесь поместить утверждение в строку после условного выражения, оберните его в фигурные скобки. Чтобы дать конкретный пример точки @ Дэниела, если я отлаживаю это:

if (number==1) 
    name="a";
if (number==2)
    name="b";

... У меня будет соблазн сделать это:

if (number==1) 
    print "Hit the first conditional\n";
    name="a";
if (number==2)
    print "No, hit the second conditional\n";
    name="b";

... и веселье во время выполнения.

Иногда я помещаю однострочную команду в ту же строку, что и оператор "if", если это что-то очевидное и простое, например, "if (inputVar == null) return;". Но, как правило, если я делаю отступ для отдельных команд (в отличие от одной большой команды, занимающей несколько строк) *, я всегда хочу, чтобы они были заключены в фигурные скобки. Таким образом, у меня меньше проблем.

* - Ладно, технически, эти однокомандные операторы if действительно являются одной командой, занимающей несколько строк. Но если я случайно вставлю команду в середину многострочного вызова метода, компилятор прекратит работу, прежде чем я смогу запутаться.

2 голосов
/ 23 апреля 2009

Я использую следующий стиль.

if (number == 1) 
{
   name = "a";
}
else if (number == 2)
{
   name = "b";
}

Это позволяет избежать ошибок при вставке новой строки.

if (number == 1) 
   DoSomething();
   name = "a";

Теперь name = "a"; больше не является условным. В настоящее время я думаю о переходе на следующий стиль.

if (number == 1) {
   name = "a";
}

Таким образом, текстовая структура более точно отражает структуру управления, но я все еще думаю об этом.

2 голосов
/ 23 апреля 2009

Я предпочитаю:

if (number==1) { 
    name="a";
}
if (number==2) name="b";

Всякий раз, когда я использую скобку, я начинаю новую строку.

1 голос
/ 05 мая 2009

При размещении условных выражений в одной строке я использую формат одной строки:

toggled = (on == true ) ? true : false;

Однако, это не работает, когда у вас есть несколько случаев, где я мог бы использовать оператор switch:

switch ( number ) {
  case 1: a;
   break;

  case 2: b;
   break;
    a;
}

Для вашего конкретного примера я бы сделал это:

if ( number == 1 ) {
  name = "a";
} else if ( number == 2 ) {
  name = "b";
}

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

1 голос
/ 23 апреля 2009

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

...