Одно утверждение, если блок - фигурные скобки или нет? [закрыто]

Что лучше / более общепринятым?

Этот:

if(condition)
{
  statement;
}

Или же:

if(condition)
  statement;

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

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

if(condition) 
//      statement;
otherStatement;

Или добавление кода в спешке:

if(condition) 
    statement;
    otherStatement;

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

if(condition) statement;

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

Я всегда использую скобки, чтобы быть в безопасности.

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

Я предпочитаю версию без брекетов, где это возможно.

Следующее объяснение длинновато. Пожалуйста, потерпите меня. Я дам вескую причину для меня, чтобы предпочесть этот стиль. Я также объясню, почему я думаю, что обычный контраргумент не имеет места.

(Почти) пустые строки - пустая трата

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

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

Однако я ненавижу тратить вертикальное пространство. Современные мониторы на самом деле имеют достаточно горизонтального пространства. Но вертикальное пространство все еще очень и очень ограничено (если только вы не используете монитор, повернутый вертикально, что не редкость). Это ограниченное вертикальное пространство является проблемой: общепризнанно, что отдельные методы должны быть как можно короче, и что соответствующие скобки (или другие разделители блоков) должны иметь разность не более высоты экрана, чтобы вы могли видеть весь блок без прокрутки.

Это фундаментальная проблема: если вы больше не видите весь блок на экране, его становится сложно понять.

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

Точно так же должны быть линии, которые просто содержат скобку и которые могут быть сэкономлены. Блок с одним оператором, который ограничен фигурными скобками, тратит одну-две строки. Это заметно только при 50-ти строчках на высоту экрана.

Пропуск скобок может не навредить

Есть только один аргумент против пропуска фигурных скобок: кто-то позже добавит еще один оператор к рассматриваемому блоку и забудет добавить фигурные скобки, тем самым непреднамеренно изменив семантику кода.

Это действительно было бы большим делом.

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

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

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

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

¹ Эта проблема иногда решается путем помещения всего, включая скобки, в одну строку:

if (condition)
{ do_something(); }

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

Я иду со вторым. Это более кратко и менее многословно.

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

Я бы использовал следующее (консенсус здесь):

if (condition) {
    any_number_of_statements;
}

Также возможно:

if(condition) single_compact_statement;

Не очень хорошо, особенно в C / C ++ - подобных языках:

if(condition) 
    single_compact_statement;

(Здесь нет выбора в Python ;-)

В Perl вы бы использовали:

$C = $A**3 if $A != $B;

или же

$C = $A**3 unless $A == $B;

(Это не псевдокод ;-)

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

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

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

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

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

Если вам нужно добавить код в ifблок, вам не нужно запоминать / искать фигурные скобки. Когда будущие программисты читают код, фигурные скобки всегда однозначны.

С другой стороны, ReSharper автоматически добавит фигурные скобки для ленивых программистов в Visual Studio, и я предполагаю, что есть дополнения для других IDE, которые также будут это делать.

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

«Не заставляй меня думать» относится не только к пользовательским интерфейсам, вы все ;-)

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

На это я говорю "не используйте макросы". Я также говорю: «Сделайте отступ в свой проклятый код правильно». Учитывая, как каждый текстовый редактор / IDE, используемый для программирования, выполняет отступы автоматически, это не должно быть так сложно сделать. При написании кода в Emacs я использовал бы автоматический отступ, чтобы определить, что я написал что-то не так в предыдущей строке. Каждый раз, когда Emacs начинает портить отступы, я обычно знаю, что сделал что-то не так.

На практике я в конечном итоге следую всем правилам кодирования, установленным до меня. Но они раздражают меня (и делает меня намного счастливее, когда я пишу код на Python, и вся эта скобочная катастрофа исчезла):

if (condition) {
    statement;
} // stupid extra brace looks ugly

затем

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Хотя, честно говоря, два утверждения в утверждении if раздражают меня гораздо больше, чем одно. Главным образом потому, что тогда требуются квадратные скобки, и это все равно выглядит смешно только с двумя операторами в операторе if.

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

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

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

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

Ниже приведены некоторые примеры, которые демонстрируют, как я использую эту форму ifутверждения.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Брекеты. Всегда. Я отчасти их фанат, потому что это дает коду некоторую последовательность. А также, как писал @dsimcha - меньше шансов на ошибки при добавлении дополнительных строк кода.

«Уродливость» фигурных скобок вокруг одной строки кода менее вредна, чем дополнительная работа, которая вероятна в тех случаях, когда выполняется отладка и / или добавление кода.

Лично я хожу со скобками.

Почему?

Хорошо, если кто-нибудь придет и должен добавить код в оператор if, то на 100% ясно, где находится область.

Он сохраняет ifсогласованный формат операторов независимо от того, сколько операторов в блоке.

Однако, если стиль проекта - без, придерживайтесь этого.

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

if (x==5) Console.WriteLine("It's a five!");

Я предпочитаю фигурные скобки для согласованности, но не теряю слишком много пустого пространства (поэтому более читаемый отформатированный код находится в моей ограниченной области обзора) Поэтому я пишу это для достаточно коротких строк:

If (cond) { statement; }

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

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Для меня было бы глупо добавлять их туда. Если кто-то добавит заявление после return, у нас будут большие проблемы, чем проблемы с ограничением объема.

Если в среде IDE доступно форматирование кода, я не использую фигурные скобки.

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