Я читаю некоторые лекционные заметки моего лектора C ++, и он написал следующее:
- Использовать отступ // OK
- Никогда не полагайтесь на приоритет оператора - всегда используйте скобки // OK
- Всегда используйте блок {} - даже для одной строки // не в порядке , почему ???
- Const объект на левой стороне сравнения // OK
- Используйте unsigned для переменных, которые> = 0 // хороший трюк
- Установите Pointer в NULL после удаления - Двойная защита удаления // не плохо
Третий метод мне не понятен: что я получу, поместив одну строку в a { ... }
?
Например, возьмите этот странный код:
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
if (i % 2 == 0)
{
j++;
}
}
и заменить его на:
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
if (i % 2 == 0)
j++;
В чем преимущество использования 1-й версии?
for (unsigned i = 100; i >= 0; --i)
.(i % 2 == 0)
противоречит (2). Вы полагаетесь на приоритет оператора, и значение, конечно,((i % 2) == 0)
а не(i % (2 == 0))
. Я бы классифицировал правило 2 как «правильное мнение, но« всегда »неправильно».Ответы:
Попробуем также изменить,
i
когда мы увеличиваемj
:о нет! Исходя из Python, это выглядит хорошо, но на самом деле это не так, поскольку это эквивалентно:
Конечно, это глупая ошибка, но она может допустить даже опытный программист.
Другая очень веская причина указана в ответе ta.speot.is .
Третий, который я могу придумать, является вложенным
if
:Теперь предположим, что вы хотите, чтобы
doSomethingElse()
когдаcond1
не встретил (новая функция). Так:что, очевидно, неправильно, поскольку
else
ассоциируется с внутреннимif
.Изменить: так как это привлекает некоторое внимание, я уточню свою точку зрения. Вопрос, на который я отвечал:
Который я описал. Есть некоторые преимущества. Но, IMO, «всегда» правила не всегда применяются. Так что я не полностью поддерживаю
Я не говорю, всегда используйте
{}
блок. Если это достаточно простое условие и поведение, не надо. Если вы подозреваете, что кто-то может прийти позже и изменить свой код, чтобы добавить функциональность, сделайте.источник
i++
раньшеj++
, то обе переменные будут по-прежнему в области видимости, когда они будут использоваться.i++;
таким способом, который сразу показывает, что он не является частью цикла. (В прошлом это могло быть разумным аргументом, и я видел такие проблемы. Около 20 лет назад. Не с тех пор.)Очень легко случайно изменить поток управления с комментариями, если вы не используете
{
и}
. Например:Если вы закомментируете
do_something_else()
однострочный комментарий, вы получите следующее:Он компилируется, но
must_always_do_this()
не всегда вызывается.У нас была эта проблема в нашей базе кода, когда кто-то очень быстро отключил некоторые функции перед выпуском. К счастью, мы обнаружили это в обзоре кода.
источник
must_always_do_this();
будет выполняться, если вы прокомментируете // do_something_else ();if(debug) \n //print(info);
, В основном вытащили целую библиотеку.Fortunately we caught it in code review.
Ой! Это звучит так неправильно.Fortunately we caught it in unit tests.
было бы намного лучше!У меня есть сомнения относительно компетентности лектора. Учитывая его пункты:
(b*b) - ((4*a)*c)
? Некоторые приоритеты очевидны (или должны быть), а лишние скобки только добавляют путаницы. (С другой стороны, вы должны использовать скобки в менее очевидных случаях, даже если вы знаете, что они не нужны.){
не так заметно, поэтому лучше предположить, что оно всегда там. Во втором, однако, у меня (и большинства людей, с которыми я работал) нет проблем с опущением скобок для одного утверждения. (При условии, конечно, что отступы являются систематическими и что вы используете этот стиль последовательно. (И многие очень хорошие программисты, пишущие очень читаемый код, опускают фигурные скобки даже при форматировании первым способом.)if ( NULL == ptr )
достаточно уродливы, что мешают читабельности. Напишите сравнения интуитивно. (Что во многих случаях приводит к константе справа.) Его 4 - плохой совет; все, что делает код неестественным, делает его менее читабельным.int
зарезервированных для особых случаев. Для опытных программистов на C и C ++ используютсяunsigned
сигналы битовых операторов. C ++ не имеет реального кардинального типа (или любого другого эффективного поддиапазонного типа);unsigned
не работает для числовых значений, из-за правил продвижения. Предполагается, что числовые значения, для которых не имеют смысла никакие арифметические операции, как, например, серийные номераunsigned
. Однако я бы поспорил с этим, потому что он посылает неверное сообщение: побитовые операции тоже не имеют смысла. Основное правило заключается в том, что целочисленные типыint
, _unless_, есть существенная причина для использования другого типа.delete this;
часто это наиболее частый случай (и вы не можете установитьthis
егоNULL
), а в остальном, большинство из нихdelete
- в деструкторах, поэтому вы все равно не сможете получить доступ к указателю позже. И установка его наNULL
ничего не делает с другими указателями, плавающими вокруг. Систематическая установка указателяNULL
дает ложное чувство безопасности и на самом деле ничего вам не дает.Посмотрите на код в любой из типичных ссылок. Страуструп нарушает каждое правило, которое вы дали, например, кроме первого.
Я бы посоветовал вам найти другого лектора. Тот, кто действительно знает, о чем говорит.
источник
delete this
, это более распространено, чем я видел? Я не склонен думать, что установка указателя на NULL после использования - плохая вещь, кроме YMMV. Может быть, это только я, но большинство его рекомендаций не кажутся такими уж плохими.if (ptr = NULL)
если вы не напишите это какif ((ptr = NULL))
. Должен согласиться с Джеймсом Канзе, что безобразие наличияNULL
сначала делает для меня это НЕТ.unsigned
указывает на стремление со стороны программиста, что переменная должна представлять только положительные числа. Смешивание со знаковыми числами обычно вызывает предупреждение компилятора, что, вероятно, было тем, что намеревался лектор.size_t
, кто угодно?Все остальные ответы защищают правило вашего лектора 3.
Позвольте мне сказать, что я согласен с вами: правило излишне, и я бы не советовал его. Это правда, что это теоретически предотвращает ошибки, если вы всегда добавляете фигурные скобки. С другой стороны, я никогда не сталкивался с этой проблемой в реальной жизни : вопреки тому, что подразумевают другие ответы, я ни разу не забыл добавить фигурные скобки, как только они стали необходимыми. Если вы используете правильные отступы, сразу становится очевидным, что вам нужно добавлять фигурные скобки, как только несколько операторов имеют отступ.
Ответ «Компонента 10» фактически выдвигает на первый план единственно возможный случай, когда это действительно может привести к ошибке. Но, с другой стороны, замена кода с помощью регулярных выражений всегда требует огромной осторожности.
Теперь давайте посмотрим на другую сторону медали: есть ли недостаток в использовании фигурных скобок? Другие ответы просто игнорируют этот пункт. Но есть недостаток: он занимает много вертикального пространства экрана, а это , в свою очередь , может сделать код нечитаемым , потому что это означает , что вы должны прокручивать больше , чем необходимо.
Рассмотрим функцию с множеством защитных предложений в начале (и да, следующее - плохой код C ++, но в других языках это было бы довольно распространенной ситуацией):
Это ужасный код, и я настоятельно утверждаю, что следующее гораздо более читабельно:
Аналогично, короткие вложенные циклы выигрывают от того, что опускаются фигурные скобки:
Сравнить с:
Первый код является кратким; второй код раздутый.
И да, это можно до некоторой степени смягчить , поставив открывающую скобку на предыдущей строке. Но это все равно будет менее читабельным, чем код без фигурных скобок.
Короче говоря: не пишите ненужный код, который занимает место на экране.
источник
if (a == nullptr) { throw null_ptr_error("a"); }
в одну строку.Кодовая база, над которой я работаю, разбросана по коду людьми с патологическим отвращением к фигурным скобкам, и для людей, которые приходят позже, это действительно может иметь значение для удобства сопровождения.
Наиболее частый проблемный пример, с которым я столкнулся, это:
Поэтому, когда я прихожу и хочу добавить заявление затем, я могу легко закончить с этим, если не буду осторожен:
Учитывая, что добавление скобок занимает ~ 1 секунду и может сэкономить вам как минимум несколько запутанных минут отладки, почему бы вам никогда не воспользоваться опцией уменьшенной неоднозначности? Похоже на ложную экономию для меня.
источник
if(really long...editor){ do_foo;}
помогло вам избежать этого случая? Похоже, что проблема останется прежней. Лично я предпочитаю избегать фигурных скобок, когда в этом нет необходимости, однако это никак не связано со временем, необходимым для их написания, но снижает читаемость из-за двух дополнительных строк в кодеМой 2с:
очевидно
Я бы не использовал слова «никогда» и «всегда», но в целом я считаю, что это правило полезно. В некоторых языках (Lisp, Smalltalk) это не проблема.
Я никогда не делал этого и никогда не сталкивался ни с одной проблемой, но я вижу, как это может быть полезно для студентов, особенно. если они изучали Python раньше.
Йода условия? Пожалуйста нет. Это вредит читабельности. Просто используйте максимальный уровень предупреждения при компиляции кода.
ХОРОШО. Забавно, но я слышал, что Страуструп не согласен.
Плохой совет! Никогда не указатель, который указывает на удаленный или несуществующий объект.
источник
unsigned
работает», одна из проблем состоит в том, что когда C ++ сравнивает подписанные и неподписанные типы одинакового размера, он выполняет преобразование в неподписанный тип перед выполнением сравнения. Что приводит к изменению стоимости. Преобразование в подписанное не обязательно будет намного лучше; сравнение должно действительно происходить «как если бы» оба значения были преобразованы в больший тип, который мог бы представлять все значения в любом типе.unsigned
. Я уверен, что у него нет проблем сexp(double)
возвратом значения больше, чемMAX_INT
:-). Но еще раз, реальная проблема - неявные преобразования.int i = exp( 1e6 );
совершенно корректно C ++. В какой-то момент Страуструп предложил отказаться от неявных преобразований с потерями, но комитет не заинтересовался. (Интересный вопрос: будет лиunsigned
->int
считаться с потерями. Я бы рассмотрел иunsigned
->int
иint
->unsigned
с потерями. Что бы иметь большое значение дляunsigned
ОКэто более интуитивно понятно и легко понятно. Это проясняет намерение.
И это гарантирует, что код не сломается, когда новый пользователь может неосознанно пропустить
{
,}
при добавлении нового оператора кода.источник
Makes the intent clear
+1, это, пожалуй, самая краткая и точная причина.Чтобы добавить к очень разумным предложениям выше, один пример, с которым я столкнулся при рефакторинге некоторого кода, где это становится критичным, был следующим: я изменял очень большую кодовую базу для переключения с одного API на другой. У первого API был вызов для установки идентификатора компании следующим образом:
тогда как для замены потребовалось два вызова:
Я решил изменить это с помощью регулярных выражений, что было очень успешно. Мы также передали код через astyle , что действительно сделало его намного более читабельным. Затем, частично пройдя через процесс обзора, я обнаружил, что при некоторых условных обстоятельствах это менялось так:
К этому:
что явно не то, что требовалось. Мне пришлось вернуться к началу, сделать это снова, обработав замену как полностью внутри блока, а затем вручную изменив все, что в конечном итоге выглядело глупо (по крайней мере, это не было бы неправильно).
Я заметил, что у astyle теперь есть опция,
--add-brackets
которая позволяет вам добавлять скобки там, где их нет, и я настоятельно рекомендую это, если вы когда-нибудь окажетесь в том же положении, что и я.источник
#define FOO() func1(); \ func2();
(с переводом строки после обратной косой черты), то же самое относится и к поиску и замене. Тем не менее, я видел «всегда использовать фигурные скобки», продвинутые в качестве правила стиля именно потому, что это избавляет вас от оборачивания всех ваших макросов с несколькими операторамиdo .. while(0)
. Но я не согласен.inline
), то вам, вероятно, следует стремиться к тому, чтобы они работали как функция, насколько это возможно, используяdo { ... } while(0)
при необходимости хитрость (и множество дополнительных скобок. Но это все равно не помогло бы). не мешать вам использовать фигурные скобки везде, если это стиль дома (FWIW: я работал в местах с различными стилями дома, охватывая все стили, обсуждаемые здесь. Я никогда не находил, что какой-либо серьезной проблемой.)Я использую
{}
везде, кроме нескольких случаев, когда это очевидно. Одна строка - это один из случаев:Это может повредить вам, когда вы добавляете какой-то метод перед возвратом. Отступы указывают, что return выполняется при выполнении условия, но он будет возвращаться всегда.
Другой пример в C # с использованием statment
что эквивалентно
источник
using
заявлении, и вам не нужно :)using
).Самый подходящий пример, который я могу представить:
Что
if
будет вelse
паре с? Отступ подразумевает, что внешнийif
получаетelse
, но на самом деле это не так, как его видит компилятор; внутреннийif
будет получитьelse
, а внешнийif
не делает. Вы должны знать это (или видеть, как он ведет себя таким образом в режиме отладки), чтобы выяснить путем проверки, почему этот код может не соответствовать вашим ожиданиям. Это становится более запутанным, если вы знаете Python; в этом случае вы знаете, что отступ определяет блоки кода, поэтому вы ожидаете, что он будет оцениваться в соответствии с отступом. C #, однако, не дает пролистывать пробелы.Тем не менее, я не особо согласен с этим правилом «всегда используйте скобки». Это делает код очень шумным в вертикальном направлении, снижая возможность его быстрого чтения. Если утверждение:
... тогда это должно быть написано так же, как это. Выражение «всегда использовать скобки» звучит как «всегда заключать математические операции в круглые скобки». Это превратит очень простое утверждение
a * b + c / d
в((a * b) + (c / d))
возможность пропустить близкого человека (проклятие многих кодеров) и для чего? Порядок операций хорошо известен и строго соблюдается, поэтому круглые скобки являются избыточными. Вы должны использовать круглые скобки только для обеспечения другого порядка операций, чем обычно применяется:a * (b+c) / d
например. Брекеты похожи; используйте их, чтобы определить, что вы хотите сделать в тех случаях, когда это отличается от значения по умолчанию и не является «очевидным» (субъективным, но обычно довольно здравым смыслом).источник
else
с первымif
вместо второго. Пожалуйста, удалите понижающий голос.Просматривая ответы, никто не указал явно, какую практику я привыкаю, рассказывая историю вашего кода:
становится:
Помещение строки в
j++
ту же строку, что и if, должно сигнализировать кому-либо еще: «Я хочу, чтобы этот блок только увеличивалсяj
» . Из coursethis имеет смысл только , если строка выглядит упрощенно , насколько это возможно, потому что поставив точку останова здесь, как пери упоминает, не собирается быть очень полезным.На самом деле, я только что натолкнулся на часть API-интерфейса Twitter Storm, который имеет такой «код» в java, вот соответствующий фрагмент кода для выполнения на странице 43 этого слайд-шоу :
В блоке for есть две вещи, поэтому я бы не стал использовать этот код. Т.е. никогда :
Это ужасно, и я даже не знаю, работает ли это (как задумано); не делайте этого . Новые строки и скобки помогают различать отдельные, но связанные фрагменты кода, точно так же, как запятая или точка с запятой в прозе. Вышеприведенный блок настолько же плох - очень длинное предложение с несколькими предложениями и некоторыми другими утверждениями, которые никогда не ломаются и не делаются паузы, чтобы различать отдельные части.
Если вы действительно хотите телеграфировать кому-то еще, это работа в одну строку, используйте троичного оператора или
?:
форму:Но это граничит с code-golf, и я думаю, что это не очень хорошая практика (мне не ясно, стоит ли мне ставить j ++ на одну сторону
:
или нет). NB Я раньше не запускал троичный оператор в C ++, я не знаю, работает ли он, но он существует .Коротко:
Представьте, как ваш читатель (т. Е. Человек, обслуживающий код) интерпретирует вашу историю (код). Сделайте это как можно более ясным для них. Если вы знаете, что начинающий программист / студент поддерживает это, возможно, даже оставьте как
{}
можно больше, просто чтобы они не запутались.источник
for
цикл в одну строку, почему это не должно работать? Это работает по той же причине, по которой вы можете опустить скобки; Новая строка просто не имеет значения в C ++. (3) Ваш пример условного оператора, кроме ужасного, является недействительным C ++.Потому что, когда у вас есть два утверждения без
{}
, легко пропустить вопрос. Давайте предположим, что код выглядит следующим образом.Выглядит хорошо. Проблема с этим действительно легко пропустить, особенно когда функция, содержащая код, намного больше. Проблема в том, что
goto fail
запускается безоговорочно. Вы можете легко представить, как это разочаровывает (заставляя вас спросить, почему последнийhash_update
всегда терпит неудачу, ведь все работает нормальноhash_update
).Тем не менее, это не значит, что я добавляю
{}
везде (по моему мнению, смотреть{}
везде раздражает). Хотя это может вызывать проблемы, этого никогда не случалось для моих собственных проектов, поскольку мой личный стиль кодирования запрещает условные выражения,{}
если они не совпадают (да, я согласен, что мой стиль кодирования нетрадиционен, но мне это нравится, и я использовать стиль кода проекта при участии в других проектах). Это делает следующий код в порядке.Но не следующий.
источник
Это делает ваш код более читабельным, четко определяя область действия ваших циклов и условных блоков. Это также спасает вас от случайных ошибок.
источник
WRT 6: это безопаснее, потому что удаление нулевого указателя не работает. Так что, если вам случится случайно пройти этот путь дважды, вы не вызовете, чтобы повреждение памяти освободило память, которая либо свободна, либо была выделена для чего-то другого.
Это большая часть проблемы со статическими объектами области видимости файлов и синглетонами, у которых не очень ясные времена жизни, и которые, как известно, воссоздаются после их уничтожения.
В большинстве случаев вы можете избежать этого, используя auto_ptrs
источник
NULL
после удаления. ЕслиNULL
это правильное значение, которое указатель должен иметь при таких обстоятельствах; например, указатель указывает на кэшированное значение иNULL
указывает на недопустимый кеш. Но когда вы видите, что кто-то настраивает указательNULL
на последнюю строку в деструкторе, вы задаетесь вопросом, знает ли он C ++.)Мне нравится принятый ответ Лучиана, на самом деле я усвоил сложный способ, что он прав, поэтому я всегда использую фигурные скобки, даже для однострочных блоков. Тем не менее, лично я делаю исключение при написании фильтра, как вы в своем примере. Это:
выглядит загроможденным для меня. Он разделяет цикл for и оператор if на отдельные действия, когда на самом деле ваше намерение - это одно действие: подсчитать все целые числа, делимые на 2. В более выразительном языке это можно записать примерно так:
В языках, в которых отсутствуют замыкания, фильтр не может быть выражен одним оператором, но должен быть циклом for, за которым следует оператор if. Тем не менее, это все еще одно действие в уме программиста, и я считаю, что это должно быть отражено в коде, например, так:
источник
for (int i = 0; i < 100; i += 2);
, ради продолжения спора об отступах ;-) Возможно, у нас может быть целый отдельный булфрайт, как «лучше» выразить логику «для каждогоi
в определенном диапазоне с определенным свойством» в C ++ без цикла, используя некую кошмарную комбинацию стандартных алгоритмовfilter_iterator
и / илиcounting_iterator
.i
в определенном диапазоне с определенным свойством». Просто на SO обычно люди очень быстро игнорируют реальный вопрос в пользу совершенно другого подхода к приведенному примеру. Но отступы важны , поэтому мы не делаем ;-)Один из способов помочь предотвратить ошибки, описанные выше, - указать, что вы хотите получить, если не используете фигурные скобки. Намного сложнее не замечать ошибки, когда вы пытаетесь изменить код.
источник
else
не связан сif
.Если вы компилятор, это не имеет никакого значения. Оба одинаковы.
Но для программистов первый более понятен, легко читается и менее подвержен ошибкам.
источник
{
любом случае, кроме открытия по собственной линии.Еще один пример добавления фигурных скобок. Однажды я искал ошибку и нашел такой код:
Если вы прочитаете метод построчно, вы заметите, что в методе есть условие, которое возвращает значение, если оно не соответствует действительности. Но на самом деле это выглядит как 100 других простых обработчиков событий, которые устанавливают некоторые переменные на основе некоторых условий. И однажды приходит быстрый кодер и добавляет дополнительный оператор установки переменных в конце метода:
В результате SetAnotherVariableUnconditionnaly выполняется, когда SomeConditionIsMet (), но быстрый парень этого не заметил, потому что все строки почти одинакового размера, и даже если условие возврата имеет отступ по вертикали, это не так заметно.
Если условный возврат отформатирован так:
это очень заметно, и быстрый кодер найдет его с первого взгляда.
источник
return
оператор в теле функции перед добавлением чего-либо в нее, вы не должны позволять быстрому кодеру приближаться к вашему коду. Вы не остановите такого парня от троллинга вокруг вашего кода, включая фигурные скобки.Я считаю, что первое ясно, а потом второе. Это дает ощущение закрытия инструкций, с небольшим кодом хорошо, когда код становится сложным, очень
{...}
помогает, даже если этоendif
илиbegin...end
источник
Лучше всего установить указатель на NULL, когда вы закончите с ним.
Вот пример почему:
Класс А делает следующее:
Класс B делает следующее
На этом этапе и класс A, и класс B имеют указатели, указывающие на один и тот же блок памяти, поскольку для класса A этот блок памяти не существует, поскольку он завершен с ним.
Рассмотрим следующую проблему:
Что если в классе A произошла логическая ошибка, из-за которой он записал в память, которая теперь принадлежит классу B?
В этом конкретном случае вы не получите ошибку исключения неправильного доступа, поскольку адрес памяти допустим, в то время как класс A теперь эффективно портит данные класса B.
Класс B может в конечном итоге аварийно завершить работу, если он встретит неожиданные значения, и, если произойдет сбой, есть вероятность, что вы потратите довольно много времени на поиск этой ошибки в классе B, когда проблема в классе A.
Если бы вы установили указатель удаленной памяти в NULL, вы бы получили ошибку исключения, как только любые логические ошибки в классе A попытались записать в указатель NULL.
Если вас беспокоит логическая ошибка с двойным удалением, когда указатели равны NULL во второй раз, то добавьте assert для этого.
Также: если вы собираетесь проголосовать против, пожалуйста, объясните.
источник
Всегда иметь фигурные скобки - очень простое и надежное правило. Однако код может выглядеть не элегантным, когда есть много скобок. Если правила позволяют опускать фигурные скобки, то должны быть более подробные правила стиля и более сложные инструменты. В противном случае это может легко привести к хаотическому и запутанному (не элегантному) коду. Поэтому поиск единого правила стиля отдельно от остальных руководств по стилю и используемых инструментов, скорее всего, бесполезен. Я просто приведу некоторые важные детали об этом правиле № 3, которые даже не упоминались в других ответах.
Первая интересная деталь заключается в том, что большинство сторонников этого правила соглашаются нарушать его в случае
else
. Другими словами они не требуют в обзоре такой код:Вместо этого, если они видят это, они могут даже предложить написать это так:
Это технически является нарушением этого правила, поскольку между
else
иif
. Такая двойственность правила возникает, когда пытаться автоматически применить его к базе кода с помощью бессмысленного инструмента. Действительно, зачем спорить, просто дайте инструменту применить стиль автоматически.Вторая деталь (которую также часто забывают сторонники этого правила), это то, что ошибки, которые могут произойти, никогда не происходят только из-за нарушений этого правила № 3. На самом деле это почти всегда связано с нарушениями правила № 1 (с которым никто не спорит). Опять же, с точки зрения автоматических инструментов, нетрудно создать инструмент, который немедленно жалуется, когда нарушается правило № 1, и поэтому большинство ошибок могут быть своевременно обнаружены.
Третья деталь (о которой часто забывают противники этого правила) - запутанная природа пустого утверждения, представленного одной точкой с запятой. Большинство разработчиков с некоторым опытом рано или поздно смутились из-за единственной неуместной точки с запятой или из-за пустого выражения, написанного с использованием единственной точки с запятой. Две фигурные скобки вместо одной точки с запятой визуально легче обнаружить.
источник
Я должен признать, что не всегда использовать
{}
для одной строки, но это хорошая практика.Допустим, вы пишете код без скобок, который выглядит следующим образом:
for (int i = 0; i <100; ++ i) для (int j = 0; j <100; ++ j) DoSingleStuff ();
И через некоторое время вы хотите добавить в
j
цикл некоторые другие вещи, и вы просто делаете это выравниванием и забываете добавлять скобки.Освобождение памяти происходит быстрее. Допустим, у вас есть большие области видимости и вы создаете большие массивы внутри (без
new
так, чтобы они были в стеке). Эти массивы удаляются из памяти сразу после выхода из области видимости. Но возможно, что вы используете этот массив в одном месте, и он какое-то время будет находиться в стеке и будет своего рода мусором. Поскольку стек имеет ограниченный и довольно маленький размер, его размер может превышать. Так что в некоторых случаях лучше написать,{}
чтобы предотвратить это. ПРИМЕЧАНИЕ, это не для одной строки, а для таких ситуаций:if (...) {// SomeStuff ... {// у нас нет if, while и т. д. // SomeOtherStuff} // SomeMoreStuff}
Третий способ его использования аналогичен второму. Это просто не для того, чтобы сделать стек чище, а чтобы открыть некоторые функции. Если вы используете
mutex
длинные функции, как правило, лучше блокировать и разблокировать непосредственно перед доступом к данным и сразу после окончания чтения / записи. Обратите внимание, что этот способ используется, если у вас есть своиclass
илиstruct
сconstructor
и иdestructor
для блокировки памяти.Что больше
if (...) if (...) SomeStuff (); еще SomeOtherStuff (); // переходит ко второму if, но аллигент показывает, что он на первом ...
В целом, я не могу сказать, каков наилучший способ всегда использовать
{}
одну строку, но в этом нет ничего плохого.ВАЖНОЕ РЕДАКТИРОВАНИЕ Если вы пишете кодовые скобки кода для одной строки, это ничего не делает, но если ваш код будет интерпретирован, это очень сильно замедляет код. Очень немного
источник
Существует несколько возможных способов написания управляющих операторов; некоторые их комбинации могут сосуществовать, не нарушая разборчивость, но другие комбинации вызовут проблемы. Стиль
будет комфортно сосуществовать с некоторыми другими способами написания управляющих операторов, но не так хорошо с другими. Если многострочные контролируемые операторы записываются как:
тогда будет визуально очевидно, какие
if
операторы контролируют одну строку, а какие контролируют несколько строк. Если, однако, многострочныеif
операторы записываются как:тогда вероятность того, что кто-то попытается расширить конструкции с одним утверждением
if
без добавления необходимых фигурных скобок, может быть намного выше.Оператор с одним оператором на следующей строке
if
также может быть проблематичным, если кодовая база существенно использует формуМое собственное предпочтение состоит в том, что наличие оператора в отдельной строке обычно улучшает удобочитаемость, за исключением случаев, когда существует много
if
операторов с похожими блоками управления, напримерв этом случае я обычно предшествую и следую за такими группами
if
операторов пустой строкой, чтобы визуально отделить их от другого кода. Наличие ряда операторов, начинающихся сif
одного и того же отступа, обеспечит четкую визуальную индикацию того, что есть что-то необычное.источник