Должны ли фигурные скобки быть на своей линии или нет? Что вы думаете об этом?
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
или это должно быть
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
или даже
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
Пожалуйста, будьте конструктивны! Объясните, почему, делитесь опытом, подкрепляйте его фактами и ссылками.
coding-style
code-formatting
Tom Wijsman
источник
источник
Ответы:
Когда я был студентом, я использовал фигурные скобки на одной строке, чтобы было меньше строк, а код печатался на меньшем количестве страниц. Смотреть на один символ в скобках, напечатанный как единственное в строке, раздражает. (окружающая среда, потеря бумаги)
Но при кодировании больших приложений доступ к некоторым строкам, содержащим только фигурные скобки, возможен с учетом ощущения «группировки».
Какой бы стиль вы ни выбрали, будьте последовательны, чтобы ваш мозг не занимался обработкой нескольких стилей в связанных частях кода . В разных сценариях (как выше) я бы сказал, что можно использовать разные стили, проще переключать контекст на высоком уровне.
источник
Вы никогда не должны делать третий метод.
Экономия на фигурных скобках может спасти вас от нескольких нажатий клавиш в первый раз, но следующий кодер добавит что-то в ваше предложение else, не заметив, что в блоке пропущены фигурные скобки, будет много боли.
Напишите свой код для других людей.
источник
В течение долгого времени я утверждал, что они имеют одинаковую ценность или настолько близки к равным, что возможная выгода от правильного выбора была намного, намного ниже стоимости спора об этом.
Быть последовательным важно , хотя. Итак, я сказал, давайте подберем монету и приступим к написанию кода.
Я видел, как программисты сопротивлялись таким изменениям раньше. Преодолей это! Я много раз менял свою карьеру. Я даже использую другие стили в моем C #, чем в моей PowerShell.
Несколько лет назад я работал в команде (~ 20 разработчиков), которая решила запросить ввод данных, а затем принять решение и затем применить его ко всей базе кода. У нас будет 1 неделя, чтобы решить.
Много стонов и глаз. Много «мне нравится мой путь, потому что он лучше», но не имеет смысла.
Когда мы изучали тонкости этого вопроса, кто-то спросил, как решить эту проблему в стиле фигурных скобок:
Обратите внимание, что не сразу очевидно, где заканчивается список параметров и начинается тело. По сравнению с:
Мы немного прочитали о том, как люди во всем мире справились с этой проблемой, и нашли шаблон добавления пустой строки после открытой фигурной скобки:
Если вы собираетесь сделать визуальный перерыв, вы можете сделать это с помощью фигурной скобки. Тогда ваши визуальные разрывы тоже станут последовательными.
Редактировать : две альтернативы решению «лишняя пустая строка» при использовании K & R:
1 / Отступ аргументов функции отличается от тела функции
2 / Поместите первый аргумент в ту же строку, что и имя функции, и выровняйте дополнительные аргументы в новых строках с этим первым аргументом.
Примеры:
1 /
2 /
/Редактировать
Я до сих пор утверждаю, что последовательность важнее других соображений, но если у нас нет установленного прецедента , тогда лучше использовать скобку на следующей строке.
источник
Кардинальные правила:
Даже если у вас нет внешних ограничений, лучше всего (IMO) найти существующий (широко используемый) стандарт кодирования или руководство по стилю и попытаться выполнить его. Если вы катите свой собственный стиль, есть большая вероятность, что вы пожалеете об этом через несколько лет.
Наконец, стиль, который реализуется / реализуется с использованием существующих средств проверки стиля и средств форматирования кода, лучше, чем тот, который необходимо «принудительно применять» вручную.
источник
Преимущество первого метода в том, что он более компактен по вертикали, поэтому вы можете разместить больше кода на экране, и поэтому я предпочитаю его. Единственный аргумент, который я услышал в пользу второго метода, заключается в том, что он облегчает объединение открывающих и закрывающих скобок, но большинство IDE для этого имеют комбинацию клавиш, и это фактически ложное утверждение вместо того, чтобы соединять открывающую скобку с закрывающей. скобка Вы можете связать закрывающую скобку с выражением «начало блока» (если, иначе, для, в то время как) на том же уровне отступа, так что так же легко определить, где находится начало блока.
Я не вижу смысла тратить всю строку только на скобки, когда предыдущая конструкция for / while / if уже визуально указывает на начало блока.
Тем не менее, я считаю, что закрывающая скобка должна быть в своей собственной строке, потому что нам нужно что-то, чтобы указать конец блока и его структуру отступа видимым образом.
источник
я предпочитаю
над
потому что строки
you.postAnswer();
гораздо проще читать и находить на первый взгляд. Во-вторых, он смешивается со строкой над ним (you.hasAnswer()
), поэтому моим глазам приходится больше фокусироваться, чтобы читать.источник
Я предпочитаю первый метод. Брекеты совершенно не стоят отдельной строки.
Дело в том, что брекеты не важны. Это просто синтаксический мусор , который абсолютно не нужен для понимания того, для чего предназначен код, его цели и способа его реализации. Они просто дань старым языкам, подобным С, где визуальная группировка операторов была невозможна из-за недостатка доступного пространства на экране.
Есть языки (Python, Haskell, Ruby), которые работают без скобок. Это только подтверждает, что фигурные скобки являются мусором, и не должны заслуживать строки для них, когда это возможно:
источник
Используйте Python и полностью обойдите аргумент.
источник
SyntaxError: not a chance
Положение фигурных скобок должно быть
метаданные
настраивается в IDE программистом. Таким образом, эти надоедливые скобки во всем коде, независимо от автора, выглядят одинаково.
источник
По-разному.
Если я пишу в Javascript или jQuery, я использую первую форму:
Но если я кодирую в C #, я использую вторую форму, потому что это канонический способ сделать это в C #.
Обратите внимание, что ваш пример может быть написан
в C #.
источник
Я предпочитаю первое, потому что мне сложнее увидеть ошибку в этом примере.
чем в этом примере
; {
Выглядит более неправильно для меня , чем линии , заканчивающейся ,;
так что я , скорее всего , чтобы заметить это.источник
Я предпочитаю небольшой вариант 1)
Почему?
Я думаю, что всегда ставить фигурные скобки в отдельную строку уменьшает читабельность. Я могу разместить на своем экране только определенное количество исходного кода. Стиль скобок 2) делает алгоритмы сложения с большим количеством вложенных циклов и условно долгими.
Тем не менее, я хочу
else
начать с новой строки, потому чтоif
иelse
принадлежат друг другу, визуально. Если есть скобка передelse
, гораздо сложнее определить, что к чему относится.3) дисквалифицирует себя. Мы все знаем, какие плохие вещи могут случиться, если вы оставите скобки и забудете об этом.
источник
else
строкой, когда это необходимо, и / или ставить пустую строку между блоком if и блоком else, чтобы вещи выглядели менее запутанными. Стиль скобок № 2 не делает ничего, кроме как дистанцирует действия от условий. СЯ где-то читал, что авторы какой-то книги хотят, чтобы их код был отформатирован так:
Но нехватка места от их издателя означала, что они должны были использовать это:
Сейчас я не знаю, правда ли это (как я не могу найти это больше), но последний стиль очень распространен в книгах.
На личном уровне я предпочитаю скобки на отдельной строке, как:
а) они указывают новую область видимости
б) легче заметить, когда у вас есть несоответствие (хотя это меньше проблема в IDE, которая выявляет ошибки для вас).
источник
Ах, Единый Истинный Стиль Скобки .
Здесь есть все, что нужно для Святого Пути - даже пророк (Ричард «Мой путь или шоссе» Столлман).
Этот парень ошибался во многих вещах, но когда дело доходит до фигурных скобок, GNU очень точен.
[Обновление] Я видел свет, и теперь поклоняюсь Аллману
источник
Второй пример, я очень хорошо разбираюсь в читаемости. Я не могу смотреть, если блоки по-другому = (
источник
Простой ответ: что легче отлаживать?
В каком случае вы сначала диагностировали проблему?
Меня не волнуют личные предпочтения (есть много других стилей, включая whitesmith и др.), И мне все равно ... до тех пор, пока это не затруднит мою способность читать код и отлаживать его.
Что касается аргумента «пустое пространство», я его не покупаю: я все равно добавляю пустые строки между логическими группами, чтобы сделать программу более понятной ...
источник
Не то, чтобы кто-то это заметил, но вот почему фигурные скобки принадлежат той же строке, что и условные (за исключением очень длинных условных выражений, но это крайний случай):
В C это допустимая конструкция:
Быстрый! Что делает этот код? Если вы ответили «бесконечный цикл, запрашивающий ввод», вы ошибаетесь! Это даже не до входа. Это пойман на
while(true)
. Обратите внимание на точку с запятой в конце. Эта модель на самом деле более распространена, чем кажется; C требует, чтобы вы объявили свои переменные в начале блока, поэтому была запущена новая.Строка кода - это мысль. Брекеты являются частью мысли, содержащей условную или петлю. Поэтому они принадлежат одной линии.
источник
;
конец блока. Именно поэтому я презираю эту систему окончания блоков, которая, по-моему, устарела, и язык Go доказывает это. Я видел эту проблему много раз, хотя не в этом сценарии. Обычно это происходит, когда они намереваются добавить что-то в утверждение и забыть.Мне нравится первый способ. Кажется, аккуратнее ИМО, и это более компактно, что мне нравится.
РЕДАКТИРОВАТЬ: Ах третий. Мне нравится этот вариант лучше всего, когда это возможно, так как он еще меньше / аккуратнее.
источник
Вы могли бы написать это:
Ответить на вопрос; Раньше я предпочитал фигурные скобки на отдельной строке, но, чтобы не думать об ошибках, возникающих при автоматической вставке точек с запятой в браузерах, я начал использовать египетский стиль для javascript. И когда я кодировал java в eclipse, я не интересовался борьбой (или настройкой) стиля скобок по умолчанию, поэтому в этом случае я тоже использовал египетский. Теперь я в порядке с обоими.
источник
postAnswer()
иdoSomething()
должен возвращать значение для троичного оператора, что часто не так: они могут очень хорошо возвращать void (без значения). а также (по крайней мере, в c #) результат?:
должен быть присвоен некоторой переменнойПочти все ответы здесь говорят о некоторой вариации «Что бы вы ни делали, придерживайтесь одного или двух».
Так что я задумался об этом на мгновение, и должен был признать, что просто не считаю это важным. Кто-нибудь может честно сказать мне, что следующее трудно следовать?
Я не уверен ни в ком другом ... но у меня абсолютно нет проблем с умственным переключением между стилями. Мне потребовалось несколько минут, чтобы понять, что сделал код, но это результат того, что я просто набрал случайный C-подобный синтаксис. :)
По моему не столь скромному мнению, открывающие скобки почти не имеют отношения к читабельности кода. Выше перечислено несколько угловых случаев, в которых тот или иной стиль имеет значение, но по большей части разумное использование пустых строк устраняет это.
FWIW, наши стили кодирования в работе используют немного более структурированную форму 1 и модифицированную форму 3. (C ++)
Мне любопытно, если бы те, кто сильно предпочитает форму 2, могли найти эту версию формы 1 лучше, просто потому, что пустая строка дает более сильное визуальное разделение.
источник
Я удивлен, что это еще не было поднято. Я предпочитаю второй подход, потому что он позволяет вам легче выбрать блок.
Когда фигурные скобки начинаются и заканчиваются в одном и том же столбце и на их собственной строке, вы можете выбрать из поля или с помощью курсора в столбце 0. Обычно это означает более щедрую область с выбором мыши или меньшее количество нажатий клавиш с выбором клавиатуры.
Первоначально я работал с фигурными скобками в той же строке, что и условные, но когда я переключился, я обнаружил, что это ускорило скорость, с которой я работал. Конечно, это не день и ночь, а то, что немного замедлит работу с фигурными скобками рядом с вашими условиями.
источник
Мне лично нравится второй способ.
Тем не менее, способ, который я собираюсь продемонстрировать, на мой взгляд, лучший, потому что это обеспечивает максимальную безопасность работы! Одноклассник из моего университета попросил меня помочь с домашней работой, и вот как выглядел его код. Вся программа выглядела как один блок. Интересно, что 95% ошибок в созданной им программе были связаны с несовпадающими скобками. Остальные 5% были очевидны после сопоставления скобок.
источник
Я лично предпочитаю первый метод, вероятно потому, что именно так я впервые выучил PHP.
Для однострочных
if
операторов я буду использоватьif (you.hasAnswer()) you.postAnswer();
Если это не так,
you.postAnswer();
но что-то намного дольше, например,you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
я, вероятно, вернусь к первому типу:Я никогда не буду использовать перенос строки, и я никогда не буду использовать этот метод, если есть также
else
оператор.это теоретическая возможность, но я бы ее не использовал. Это должно быть превращено в
источник
Они не должны; Первый метод для меня.
Когда я смотрю на вторую, из-за неиспользуемых строк (те, на которых есть только фигурные скобки, кроме самой последней закрывающей фигурной скобки), я чувствую, что нарушает непрерывность кода. Я не могу читать это так быстро, потому что мне нужно уделять особое внимание пустым строкам, которые обычно означают разделение в целях кода или что-то вроде этого, но ни в коем случае «эта строка принадлежит фигурной скобке» (которая только повторяет значение отступа).
В любом случае, так же, как когда вы пишете текст ... добавление отступа в начале абзаца излишне, если перед ним стоит пустая строка (двойной знак изменения абзаца), нет необходимости тратить строки на фигурные скобки, когда мы правильно отступ.
Плюс, как уже говорилось, это позволяет разместить больше кода на экране, что в противном случае немного контрпродуктивно.
источник
Это зависит от платформы / языка / соглашений
В Java:
В C #
В С:
Я ненавижу, когда парни Java используют свой стиль в коде C # и наоборот.
источник
Все, что я могу сказать, это то, что если вы поклонник метода № 3, вас будут преследовать все средства форматирования кода IDE на земле.
источник
Я использую первый метод просто потому, что он более компактен и позволяет больше кода на экране. У меня самого никогда не было проблем с сопряжением фигурных скобок (я всегда выписываю их вместе с
if
оператором перед добавлением условия, и большинство сред позволяют перейти к соответствующей фигурной скобке).Если же нужно паре скобок визуально, то я предпочел бы второй метод. Однако это позволяет меньше кода за один раз, что требует от вас больше прокрутки. И это, по крайней мере для меня, оказывает большее влияние на чтение кода, чем аккуратно выровненные фигурные скобки. Я ненавижу скроллинг. Опять же, если вам нужно прокрутить один
if
оператор, он, скорее всего, слишком большой и требует рефакторинга.Но; самая важная вещь - последовательность. Используйте один или другой - никогда оба!
источник
Когда я впервые начал изучать программирование в 12 лет, я поставил скобки на следующую строку, потому что учебники Microsoft по кодированию такие же. Я также отступил с 4 пробелами TABS в то время.
Через несколько лет я выучил Java и JavaScript и увидел больше кода в скобках, поэтому я изменился. Я также начал делать отступы в двухпространственных пространствах.
источник
Существует 4-й вариант, который удерживает фигурные скобки, но не теряет места:
Единственная проблема заключается в том, что большинство автоформаторов IDE задыхаются от этого.
источник
Все зависит от вас, если вы не работаете над проектом, в котором менеджер проекта установил некоторые ограничения кодирования или стандарты, которым должны следовать все программисты, работающие над этим проектом во время кодирования.
Я лично предпочел бы 1-й метод.
Кроме того, я не получил то, что вы хотите показать по 3-му методу?
Разве это не неправильно? Например, рассмотрим ситуацию как ..
А что если кто-то захочет добавить еще несколько операторов в блок if ?
В этом случае, если вы используете третий метод, компилятор выдаст синтаксическую ошибку.
источник