Являются ли одинарные заявления или заявления без привязок плохой практикой?

Ответ 1

Лучшая практика - написать код, который другие могут легко читать и обновлять.

Ваша первая форма сомнительна, потому что она не соответствует формам, к которым привыкли большинство разработчиков PHP:

if (condition) {
  // code
} else {
  // code
}

// ... or ...

if (condition)
{
  // code
}
else
{
  // code
}

// ... or ...

if (condition) { /* short code */ } else { /* short code */ }

// ... or ...

condition ? /* short code */ : /* short code */;

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

Ваша вторая форма, что более важно, не так хороша, потому что это облегчает для другого программиста эту ошибку:

if (condition)
  // code A
else
  // code B
  // code C (added by another programmer)

В этом примере другой программист добавил code C, но забыл обернуть весь блок else в фигурные скобки. Это вызовет проблемы. Вы можете защитить от этого, просто обернув блоки if и else в фигурные скобки.

Ответ 2

Мое предпочтение, если для согласованности... так:

if(...)
{
   statement 1;
   statement 2;
}
else
{
   statement 1;
   statement 2;
}

не отличается от:

if(...)
{
   statement 1;
}
else
{
   statement 1;
}

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

Однако другие люди будут смотреть на мой код и думать, что глупо вставлять {и}. У них есть свои причины, у меня есть мои... Мне нравятся мои причины больше, чем мне нравятся: -)

Ответ 3

Обычно нечитаемый код является плохой практикой. Одна строка более эффективна при наборе текста и сохраняет номера строк, но возвращайтесь к ней через год или пока вы сканируете ошибки, и это затруднит процесс.

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

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

читаемым! Легко самоочевидно.

Ответ 4

Проблема, которую я видел, - это разработчики, не признающие {} -less-if, если они добавляют код к одному из условий. Пример:

//before
if(something)
    statement;

//after
if(something)
    statement;
    addedstatement;

Очевидно, что это не будет делать то, что они ожидают.

Ответ 5

Вы когда-нибудь видели такой код на C или С++?

    /*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

Отступ недействителен или программа не работает, потому что "else" всегда применяется к ближайшему "if", если вы не используете фигурные скобки.

(Давайте просто использовать python. Без скобок, просто чистые пробелы.: P)

Ответ 6

Для всех, кроме кратчайших, используйте фигурные скобки и коснитесь их соответственно. Вы хотите сделать это по нескольким причинам:

• Сложнее ошибиться, если что-то пойдет.

• Легче читать.

• В языках с возможностями макрорасширения (например, C, С++) отказ включить фигурные скобки приведет к запутывающим логическим ошибкам, когда макрос, содержащий несколько операторов, расширяется внутри незашифрованного if-else.

Ответ 7

Одним из основных преимуществ использования нескольких строк является простота отладки. Если у вас есть оператор if else, все в одной строке, и отладчик сообщает вам, что строка x взорвалась, сложнее определить, какая часть инструкции не удалась. Несколько строк также облегчают переход вашего кода с помощью отладчика.

Ответ 8

Это две строки длиной, поэтому не одна строка.

Нет ничего плохого в одиночной строке if, когда код упрощает чтение.

Например, что-то вроде этого:

if (last_item) print ", and " else print ", "

намного лучше, чем

if (last_iem)
{
    print ", and "
}
else
{
    print ", "
}

Ответ 9

Это больше стиль кодирования, чем что-либо еще. Тем не менее, мое личное мнение заключается в том, что ваш второй пример потенциально весьма вреден. Это достаточно просто, чтобы случайно "добавить вторую строку к блоку" в языках, где фигурные скобки - единственный способ создания блоков. Но на PHP, где существует альтернативный синтаксис, это еще менее вероятно, чтобы вывести необходимые предупреждающие сигналы:

if ($_GET["asdf"]==1):
    /* do something */
else:
    /* do something */
endif;

Правило большого пальца: если вы собираетесь поместить свое "сделать что-то" на отдельной строке, используйте фигурные скобки; если вы не собираетесь использовать фигурные скобки, поместите его в одну строку!

Ответ 10

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

if(){}
else (){}

Я использую if() {} в той же строке, когда это короткая инструкция, и она одна. Если в другом случае используется long:

if(checkSomething)
{
   //dosomething
}
else
{
   //doanotherthing
}

Ответ 11

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

if (x == 0)
    x = 2;
else
    print("x is: %d", x); // debugging!
    x = 4;

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

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

Ответ 12

Вы должны поместить "if" и "do something" на отдельные строки, чтобы сделать ваш код более дружественным для интерактивных отладчиков.

Если вы помещаете как "if", так и "do something" в одну строку, вы не можете установить точку останова только на строке "сделать что-то".