Должны ли фигурные скобки появляться на собственной линии? [закрыто]

274

Должны ли фигурные скобки быть на своей линии или нет? Что вы думаете об этом?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

или это должно быть

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

или даже

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Пожалуйста, будьте конструктивны! Объясните, почему, делитесь опытом, подкрепляйте его фактами и ссылками.

Tom Wijsman
источник
105
Я считаю "== true" более отвлекающим, чем выбор размещения фигурных скобок.
Дэн Дайер
11
@Dan: я думаю, что всегда объяснение условного выражения очень помогает в ясности.
Wizard79
4
Единственная причина, по которой это имеет значение, заключается в том, что ваш IDE / редактор не поддерживает распознавание фигурных скобок.
leeand00
4
@ leeand00: некоторые из нас все еще распечатывают сложный / незнакомый код, чтобы изучать / комментировать его. Хороший симпатичный принтер смягчает большинство проблем.
Shog9
2
печально вопрос закрыт. После некоторого времени использования синтаксиса на основе отступа я переключился (возможно, странно) на другую структуру скобок. Как ваша первая, но закрывающая скобка в последней строке блока. (после строки кода)
cnd

Ответы:

88

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

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

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

dbza
источник
6
С другой стороны, скобка на новой линии - это стандарт ANSI, K & R - нет. Но прелесть стандартов в том, что их так много (см. Также uncyclopedia.wikia.com/wiki/AAAAAAAAA ! На uncyclopedia).
затруднение
"Есть меньше строк" У меня есть терабайты пространства и много пикселей. Почему я должен заботиться об использовании большего количества строк?
12431234123412341234123
1
@ 12431234123412341234123: Я думаю, что он имеет в виду, потому что некоторые люди распечатывают код для проверки кода. И каждый не совсем необходимый перевод новой строки - это бумажная трата впустую, или километр Форрест, потраченный впустую в масштабе. Однако, если вы не распечатываете его (я, конечно, не), тогда ANSI намного лучше, чем K & R. Кроме того, любой, кто собирается печатать, вероятно, должен использовать автоматический форматировщик кода - так что это должен быть вопрос инструментов, а не стиля кодирования.
затруднение
247

Вы никогда не должны делать третий метод.

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

Напишите свой код для других людей.

rhettg
источник
113
Хотел бы я знать, откуда взялся этот маленький кусочек мудрости. Потому что писать свой код для людей, которые не потрудятся его прочитать, настолько бессмысленно, насколько это возможно ...
Shog9
69
Второй программист может добавить свои собственные фигурные скобки, когда он что-то добавляет. Он не глуп, и в соглашении о кодировании, которое поощряет опускание скобок для простых вещей вроде этого, он будет знать, как выглядеть.
Кен Блум
25
Дополнительные скобки не являются обязательными. Есть несколько худших дизайнерских решений, которые были приняты в C и переданы его потомкам. То, что он живет на языке, столь же недавнем, как C #, вызывает у меня ярость.
Адам Кроссленд
28
Неважно, насколько вы умны или насколько укоренился стандарт кодирования вокруг пропущенных фигур в одной строке: если вы хотите решить проблему или ошибку, вы, скорее всего, упустите из виду, что они были опущены. И в общей сложности 2 секунды работы, действительно ли так плохо быть явным?
Иордания
11
У стиля № 3 есть одно преимущество, которого вы все упускаете: вы получаете больше кода на экране одновременно.
Лорен Печтел
203

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

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

Я видел, как программисты сопротивлялись таким изменениям раньше. Преодолей это! Я много раз менял свою карьеру. Я даже использую другие стили в моем C #, чем в моей PowerShell.

Несколько лет назад я работал в команде (~ 20 разработчиков), которая решила запросить ввод данных, а затем принять решение и затем применить его ко всей базе кода. У нас будет 1 неделя, чтобы решить.

Много стонов и глаз. Много «мне нравится мой путь, потому что он лучше», но не имеет смысла.

Когда мы изучали тонкости этого вопроса, кто-то спросил, как решить эту проблему в стиле фигурных скобок:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Обратите внимание, что не сразу очевидно, где заканчивается список параметров и начинается тело. По сравнению с:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Мы немного прочитали о том, как люди во всем мире справились с этой проблемой, и нашли шаблон добавления пустой строки после открытой фигурной скобки:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

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

Редактировать : две альтернативы решению «лишняя пустая строка» при использовании K & R:

1 / Отступ аргументов функции отличается от тела функции

2 / Поместите первый аргумент в ту же строку, что и имя функции, и выровняйте дополнительные аргументы в новых строках с этим первым аргументом.

Примеры:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

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

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

Jay Bazuzi
источник
33
К вашему сведению, я могу звучать как разумный человек, но на самом деле я чокнутый. Для простых однострочных блоков я не буду использовать ни фигурные скобки, ни переводы строк, так как 'if (foo) bar ()' будет одной строкой. Я стараюсь сделать свой код достаточно простым, чтобы это не было проблемой.
Джей Базузи
38
Пришел сюда, чтобы опубликовать именно это. Множество людей, которые держат открывающую скобку в одной строке, сопровождают ее пустой строкой (особенно в начале классов и методов), потому что в противном случае трудно отделить заголовок класса / метода от тела. Что ж, если вы все равно собираетесь использовать дополнительную строку, вы можете также поставить скобку там и получить дополнительное преимущество отступа, которое будет легче увидеть.
Евгений Брикман
27
Я не видел пустую строку - я больше знаком с двойным отступом параметров для MyFunction (), когда они уходят на другую строку.
Арманд
34
Разбивать параметры на несколько строк, как это сводит с ума.
Fosco
10
Аргумент «параметр функции» - красная сельдь. Очевидно, что аргументы должны быть двойными. Нет проблем, чтобы отличить его от следующего кода.
Дэвид Онгаро
99

Кардинальные правила:

  1. Следуйте существующему стандарту кодирования проекта.
  2. Если нет стандарта кодирования, и вы редактируете существующую кодовую базу, принадлежащую кому-то другому - будьте совместимы со стилем существующего кода, независимо от того, насколько он вам нравится / не нравится.
  3. Если вы работаете над проектом «зеленого поля» - обсудите это с другими членами команды и пришли к единому мнению относительно формального или неформального стандарта кодирования.
  4. Если вы работаете над проектом «зеленого поля» в качестве единственного разработчика - решайтесь сами, а затем будьте безжалостно последовательны.

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

Наконец, стиль, который реализуется / реализуется с использованием существующих средств проверки стиля и средств форматирования кода, лучше, чем тот, который необходимо «принудительно применять» вручную.

Стивен С
источник
10
Этот ответ заслуживает большего количества голосов.
AShelly
1
согласованность - это ключ
MediaVince
70

Преимущество первого метода в том, что он более компактен по вертикали, поэтому вы можете разместить больше кода на экране, и поэтому я предпочитаю его. Единственный аргумент, который я услышал в пользу второго метода, заключается в том, что он облегчает объединение открывающих и закрывающих скобок, но большинство IDE для этого имеют комбинацию клавиш, и это фактически ложное утверждение вместо того, чтобы соединять открывающую скобку с закрывающей. скобка Вы можете связать закрывающую скобку с выражением «начало блока» (если, иначе, для, в то время как) на том же уровне отступа, так что так же легко определить, где находится начало блока.

Я не вижу смысла тратить всю строку только на скобки, когда предыдущая конструкция for / while / if уже визуально указывает на начало блока.

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

оборота EpsilonVector
источник
12
Нет ... Я говорю, зачем уменьшать объем кода, который может уместиться на вашем экране, делая что-то, что не добавляет ясности к коду?
EpsilonVector,
6
Когда я начинал кодировать, мне нравилась каждая скобка в отдельной строке, теперь я предпочитаю первый метод
NimChimpsky
57
Существует огромное количество исследований, восходящих к раннему веку Steam (Вайнберг, «Психология компьютерного программирования»), которое показывает, что понимание программистом падает ДРАМАТИЧЕСКИ, когда количество кода, который должен быть просмотрен, больше, чем может быть увиденным за один раз (т. е. один экран, одна страница принтера). Это явление убедительно доказывает, что вертикальное пространство является ценным ресурсом, который не нужно тратить даром, и поэтому предпочтительным является первый метод.
Джон Р. Штром
10
LOL @ "тратить всю линию". О, МОЙ БОГ! Не то !! = P
Ник Шпрайцер
6
@Julio В колледже я сильно предпочитал метод 1 и не мог читать метод 2. После работы в компании, которая использует C #, где стандартом является метод 2, я тоже полюбил это. Теперь я могу читать или использовать либо; никто не мешает мне. Люди, у которых есть сильная неприязнь к тому или иному, обычно слишком остро реагируют на то, что им незнакомо.
KChaloux
47

я предпочитаю

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

над

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

потому что строки you.postAnswer();гораздо проще читать и находить на первый взгляд. Во-вторых, он смешивается со строкой над ним ( you.hasAnswer()), поэтому моим глазам приходится больше фокусироваться, чтобы читать.

JD Исаакс
источник
7
Это верно, пока ваша программа не превысит высоту вашего экрана. ;)
weberc2
13
@ weberc2 Я думаю, что когда ваша программа превысит высоту экрана, на две строки меньше не изменится.
Mageek
13
10 лет назад я бы договорился о пространстве экрана. Сегодня я использую экран 1920 * 1200. Это соответствует МНОГО кода, больше, чем мой мозг может обработать одновременно. Первый способ позволяет мне вернуться назад и увидеть, как открываются / закрываются разные области видимости, не читая их.
LightStriker
3
Я никогда не мог понять, почему я предпочел этот метод, но именно для этого.
Деклан МакКенна
2
@Mageek Это запоздало, но это не 2 строки, это 2 строки для каждой области. Это O (N), а не O (1). Я на самом деле не так сильно чувствую это; более важно выбрать стиль, который делает длинные списки параметров читабельными.
weberc2
38

Я предпочитаю первый метод. Брекеты совершенно не стоят отдельной строки.

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

Есть языки (Python, Haskell, Ruby), которые работают без скобок. Это только подтверждает, что фигурные скобки являются мусором, и не должны заслуживать строки для них, когда это возможно:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}
П Швед
источник
7
Я не знаю о Haskell или Ruby, но Python чувствителен к пробелам, поэтому для обозначения блоков ему не нужны скобки или другие разделители. Скобы - это не просто синтаксический шум; они служат реальной цели.
Роберт Харви
14
@Robert, В C вы должны сделать как пробелы и скобки. В Python вы должны делать только пробелы. Как лучше?
P Shved
5
@Pavel, в C 'вам не нужно делать пробелы.
Кен Блум
7
Программы @KenBloom C без пробелов невозможно прочитать. Так что вы должны сделать их в любом случае.
П Швед
6
Независимо от того, являются ли фигурные скобки хорошей идеей или нет, само существование языков, которые их не используют, не кажется аргументом за или против них. Это только говорит о том, что можно иметь язык без них, а не о том, что это хороший или плохой языковой дизайн.
Джейсон
37

Используйте Python и полностью обойдите аргумент.

Марк Рэнсом
источник
17
+1SyntaxError: not a chance
Сет
6
Это просто не вариант для подавляющего большинства проектов. Кроме того, для группы с отступами есть свои проблемы.
Брайан Оукли
@ Брайан, я понимаю, что это не очень практично. Я просто думал, что это должна быть точка зрения, более сильная, чем просто комментарий. И я никогда не сталкивался с проблемами, вызванными отступами, которые вы подразумеваете, вероятно потому, что я не смешиваю табуляцию и пробелы.
Марк Рэнсом
Используйте Go и полностью обойдите аргумент (плюс статическая типизация, скорость и компилятор!) :)
weberc2
4
Затем нажмите клавишу пробела слишком много раз и наблюдайте, как компилятор / интерпретатор смеется над вами. Это не произойдет в большинстве языков.
Pharap
28

Положение фигурных скобок должно быть

метаданные

настраивается в IDE программистом. Таким образом, эти надоедливые скобки во всем коде, независимо от автора, выглядят одинаково.

Джонатан
источник
7
Полностью согласен. Это презентация, а не данные.
петруза
Проблема в том, что если вы позволите всем устанавливать свои собственные, все очень быстро запутывается, когда выполняются коммиты.
Энди
1
@Andy: В этом-то и дело, IDE изменит свой внешний вид, но только в IDE! Фактический источник не будет затронут. Для контроля версий вы можете добавить хуки, которые переводят любые настройки фигурных скобок в обычную ситуацию, так что каждый проверяет код одинаково.
Клар
@klaar Каждая современная IDE, которую я использовал, будет заменять табуляцию пробелами и переносить фигурные скобки на собственную линию или в конец строки «открытия»; Я не уверен, почему вы думаете, что источник не затрагивается в этих случаях, и это причина моего комментария. Как правило, он изменяется в среде IDE в зависимости от настроек разработчика, что означает, что во время коммита я буду видеть множество изменений, которые являются просто шумом, поскольку скобки перемещены на свою собственную линию, таким образом скрывая фактическое изменение, сделанное кем-то.
Энди
@ Энди: Разве нет возможности использовать ловушки, которые преобразуют эти расхождения в отношении пробелов и фигурных скобок в единый стандартный коммит uppon, чтобы обойти проблему шума, которую вы описали? В любом случае, правильная система управления версиями должна выходить за рамки мелких вещей, таких как пробелы или другие бессмысленные вещи.
Клар
19

По-разному.

Если я пишу в Javascript или jQuery, я использую первую форму:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Но если я кодирую в C #, я использую вторую форму, потому что это канонический способ сделать это в C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Обратите внимание, что ваш пример может быть написан

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

в C #.

Роберт Харви
источник
1
Он может быть написан на многих таких языках, потому что блок-оператор является оператором. Добавление! :-)
Тамара Вийсман
2
В соответствии с «Руководством по проектированию рамок» «каноническим способом» является размещение открывающей скобки на одной линии (т. Е. Первой форме). Просто
говорю
3
@ Uwe: Возможно. Но Microsoft приняла подход «выровненных фигурных скобок» для всех своих примеров MSDN C #, и он встроен в Visual Studio, так что ...
Роберт Харви,
@Uwe: Это книга Квалины, и она ужасно названа, потому что это намного больше, чем это. FDG на MSDN нечего сказать по этому поводу. Также мне интересно, почему в Руководстве по дизайну фреймворка что-то говорится о практике кодирования на C # ?
Р. Мартиньо Фернандес
3
На самом деле вы должны поместить фигурные скобки в одну строку в Javascript. Вы можете вызвать ошибки, если фигурные скобки находятся на отдельной строке. Например, см. Encosia.com/…
Джозеф Хансен
18

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

if (value > maximum);
{
    dosomething();
}

чем в этом примере

if (value > maximum); {
    dosomething();
}

; {Выглядит более неправильно для меня , чем линии , заканчивающейся , ;так что я , скорее всего , чтобы заметить это.

BMB
источник
11
Вы приводите хороший аргумент, но лично со мной такое случалось только один раз за 5 лет программирования. Я не мог понять, почему это не выполнялось, разместил это на SO, и кто-то быстро указал мне точку с запятой. Тем не менее, каждый раз, когда сокращается использование этой строки на 1, мне все труднее читать.
Джей Ди Айзекс
6
"; {" Выглядит как своего рода подмигивающее сварливое лицо или, может быть, человек с усами.
Гленатрон
+1 Отличный пример в ответе: очень тонкая ошибка, которую легко не заметить. Мысль провоцирует тоже на макет, показывающий это.
therobyouknow
10
Конечно, любая приличная IDE помечает пустой оператор управления, и любой приличный компилятор выдаст предупреждение.
Данк
@Dunk Единственный недостаток в вашем аргументе (с которым я решительно согласен) заключается в том, что в наши дни очень много людей используют интерпретируемые языки (JavaScript, PHP и др.), Что многие «программисты» не знают компилятор с двойного латте.
Крейг
15

Я предпочитаю небольшой вариант 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Почему?

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

  • Тем не менее, я хочу elseначать с новой строки, потому что ifи elseпринадлежат друг другу, визуально. Если есть скобка передelse , гораздо сложнее определить, что к чему относится.

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

Александр Гесслер
источник
1
Я видел это вокруг, где я работаю. Это интересно.
Almo
1
Мне также больше нравится этот стиль, так как он позволяет мне размещать комментарии над elseстрокой, когда это необходимо, и / или ставить пустую строку между блоком if и блоком else, чтобы вещи выглядели менее запутанными. Стиль скобок № 2 не делает ничего, кроме как дистанцирует действия от условий. С
учетом вышесказанного
4
Если важно максимизировать количество строк кода на экране, просто покончите с новыми строками. Вы сможете получить много строк на одном экране. Я предпочитаю, чтобы у меня не было ничего, что заставляло бы меня останавливаться и думать во время чтения, т.е. мое определение более читабельно. С помощью брекетов мой разум их игнорирует. Без скобок мой разум должен приостановить и выровнять блоки управления. Не долгая пауза, но пауза тем не менее.
Данк
1
Да, если и когда-либо принадлежат друг другу, НО, так что {и} и as} находятся на отдельной строке, {также должно быть на отдельной строке. «Я могу разместить на своем экране только определенное количество исходного кода». И именно поэтому сказать, что 3) будет «дисквалифицировать себя», совсем не вариант. После десятилетия работы с 3) я никогда не забывал добавлять скобки при добавлении новой строки кода, и при этом я не знаю никого, кто когда-либо имел. Если мне нужно настроить код для людей, которые не могут правильно читать, где это заканчивается? Прекращение использования определенных функций языка, потому что некоторые читатели кодов могут их не понимать?
Кайзерлуди
10

Я где-то читал, что авторы какой-то книги хотят, чтобы их код был отформатирован так:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Но нехватка места от их издателя означала, что они должны были использовать это:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

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

На личном уровне я предпочитаю скобки на отдельной строке, как:

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

ChrisF
источник
... Второй вариант также облегчает обе ваши точки (с одним отступом, служащим цели комбинации скобка / отступ). :)
weberc2
10

Ах, Единый Истинный Стиль Скобки .

Здесь есть все, что нужно для Святого Пути - даже пророк (Ричард «Мой путь или шоссе» Столлман).

Этот парень ошибался во многих вещах, но когда дело доходит до фигурных скобок, GNU очень точен.


[Обновление] Я видел свет, и теперь поклоняюсь Аллману

оборота Mawg
источник
9
Я не вижу смысла в стиле GNU, кроме того, что он моделирует код lisp. Похоже, много работы за небольшую выгоду.
Роберт Харви
Я не знаю никого, кто бы использовал стиль GNU. 1TBS полностью.
Jé Queue
Вы не можете сделать ничего хуже, чем два уровня отступа на блок, за исключением стиля lisp, что само собой разумеется.
ergosys
4
+1 за ссылку на стили скобок. Это показывает, что независимо от вашего стиля, многие великие люди не согласны с вами.
Florian F
@RobertHarvey Никакой дополнительной работы нет, если она есть, вы не используете правильный инструмент для написания кода или не настраиваете его правильно. Преимущество заключается в гораздо более удобочитаемом коде, вы видите каждую ошибку в скобках очень быстро, и вы можете легко читать только код, игнорируя при этом субблоки.
12431234123412341234123
9

Второй пример, я очень хорошо разбираюсь в читаемости. Я не могу смотреть, если блоки по-другому = (

Брайан Харрингтон
источник
1
Исследования показывают, что легче читать компактный код, когда база кода превышает высоту экрана.
weberc2
5
@ weberc2, не могли бы вы предоставить DOI для этой исследовательской работы?
Гжегож Адам Ковальски
9

Простой ответ: что легче отлаживать?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

В каком случае вы сначала диагностировали проблему?

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

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

Матье М.
источник
1
Их так же легко отлаживать, в основном потому, что это короткий блок кода. Отступы последовательны, что позволяет легко визуализировать фактические блоки кода.
Htbaa
@Htbaa: действительно :) Так зачем?
Матье М.
@MatthieuM. Первый блок имеет больше смысла для меня, потому что переводы строки (во втором блоке) между сигнатурой функции, оператором for и оператором if заставляют меня верить, что они не связаны, но, очевидно, это не так. Пустые строки должны отделять несвязанные биты кода; код, близкий к другим строкам кода, означает, что они на самом деле связаны. Это все, конечно, «имо», но мне было интересно, в чем твоя точка зрения. РЕДАКТИРОВАТЬ: также любая надлежащая IDE заметит пропущенную фигурную скобку и даст вам небольшое количество ошибок при интерпретации вашего кода.
Клар
7

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

В C это допустимая конструкция:

в то время как (истинно);
{
    символ с;
    GetChar (); // Ждем ввода
}

Быстрый! Что делает этот код? Если вы ответили «бесконечный цикл, запрашивающий ввод», вы ошибаетесь! Это даже не до входа. Это пойман наwhile(true) . Обратите внимание на точку с запятой в конце. Эта модель на самом деле более распространена, чем кажется; C требует, чтобы вы объявили свои переменные в начале блока, поэтому была запущена новая.

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

Кристиан Манн
источник
Это лучший аргумент в пользу стиля K & R, который я когда-либо видел, а остальные смехотворны в современных системах IDE с поддержкой свертывания кода. Это относится только к языкам стиля C, которые поддерживают ;конец блока. Именно поэтому я презираю эту систему окончания блоков, которая, по-моему, устарела, и язык Go доказывает это. Я видел эту проблему много раз, хотя не в этом сценарии. Обычно это происходит, когда они намереваются добавить что-то в утверждение и забыть.
Джереми
5

Мне нравится первый способ. Кажется, аккуратнее ИМО, и это более компактно, что мне нравится.

РЕДАКТИРОВАТЬ: Ах третий. Мне нравится этот вариант лучше всего, когда это возможно, так как он еще меньше / аккуратнее.

оборота Уллаллуллоо
источник
5

Вы могли бы написать это:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Ответить на вопрос; Раньше я предпочитал фигурные скобки на отдельной строке, но, чтобы не думать об ошибках, возникающих при автоматической вставке точек с запятой в браузерах, я начал использовать египетский стиль для javascript. И когда я кодировал java в eclipse, я не интересовался борьбой (или настройкой) стиля скобок по умолчанию, поэтому в этом случае я тоже использовал египетский. Теперь я в порядке с обоими.

FeatureCreep
источник
для использования таким образом, postAnswer()и doSomething()должен возвращать значение для троичного оператора, что часто не так: они могут очень хорошо возвращать void (без значения). а также (по крайней мере, в c #) результат ?:должен быть присвоен некоторой переменной
ASh
4

Почти все ответы здесь говорят о некоторой вариации «Что бы вы ни делали, придерживайтесь одного или двух».

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

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

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

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

FWIW, наши стили кодирования в работе используют немного более структурированную форму 1 и модифицированную форму 3. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

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

jkerian
источник
4
Как показывает ваш пример, отступы гораздо важнее, чем фигурные скобки для читаемого кода. Фактически, некоторые языки делают отступы единственным способом вложения утверждений!
1
Хорошо, я честно нахожу вам непоследовательный пример трудным для чтения. Не очень сложно, но сложнее, чем если бы оно было последовательным.
Almo
Я согласен с Almo. Это не случай "это действительно трудно". Это случай «это определенно сложнее», даже если не трудно. Так зачем все усложнять? В «игрушечных» примерах, которые люди приводят, разницы, конечно, мало. По моему опыту, когда я наследую неприятный код от кого-то другого, и он использует метод 1, довольно часто возникает необходимость пойти дальше и превратить его в метод 2, чтобы иметь возможность следовать логике. Из-за того, что это становится часто необходимым; он автоматически отвечает на вопрос, какой метод лучше и проще для понимания.
Данк
@Dunk: Я не могу понять код, который был бы заметно улучшен, если поменять местами такие нерелевантные детали.
jkerian
@ jkerian-Очевидно, вы не унаследовали много кода от тех, кто давно покинул проект или компанию. Я не могу понять, не сталкивался ли кто-либо с таким опытом в этой ситуации. Но опять же, у всех рабочая ситуация иная. Кроме того, если вам приходится делать «формальные» проверки кода, форматирование имеет большое значение. Умение читать код естественно очень важно. Конечно, я могу сделать паузу и подумать, чтобы подобрать брекеты, но это замедляет процесс. Один способ не требует паузы, другие делают. Вот почему я не понимаю, почему можно было бы рекомендовать любой другой выбор.
Данк
4

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

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

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

Тим О'Нил
источник
Старые таймеры, такие как я, используют три нажатия клавиш, чтобы выбрать блок, где бы ни находились эти чертовы скобки.
ergosys
2

Мне лично нравится второй способ.

Тем не менее, способ, который я собираюсь продемонстрировать, на мой взгляд, лучший, потому что это обеспечивает максимальную безопасность работы! Одноклассник из моего университета попросил меня помочь с домашней работой, и вот как выглядел его код. Вся программа выглядела как один блок. Интересно, что 95% ошибок в созданной им программе были связаны с несовпадающими скобками. Остальные 5% были очевидны после сопоставления скобок.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);
AndrejaKo
источник
8
Плохо, плохо, я имею в виду ужасный, ужасный пример. Проблема не в брекетах! Это сумасшедший отступ!
Р. Мартиньо Фернандес
@Martinho Fernandes Я думал, что установка скобок и отступов идут вместе ...
AndrejaKo
2
не обязательно ... сделайте правильный абзац на вышеупомянутом и затем случайным образом переключите стили скобок, вы поймете, что это понятно.
jkerian
На самом деле, размышления об этом мотивировали мой собственный ответ на этот вопрос.
jkerian
«95% ошибок в программе, которую он сделал, были связаны с несовпадающими скобками» - только на интерпретированных языках, а не скомпилированных.
Mawg
2

Я лично предпочитаю первый метод, вероятно потому, что именно так я впервые выучил PHP.

Для однострочных ifоператоров я буду использовать

if (you.hasAnswer()) you.postAnswer();

Если это не так, you.postAnswer();но что-то намного дольше, например, you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);я, вероятно, вернусь к первому типу:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Я никогда не буду использовать перенос строки, и я никогда не буду использовать этот метод, если есть также elseоператор.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

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

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}
наряжать
источник
2

Они не должны; Первый метод для меня.

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

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

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

Joanis
источник
2

Это зависит от платформы / языка / соглашений

В Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

В C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

В С:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Я ненавижу, когда парни Java используют свой стиль в коде C # и наоборот.

оборота ОскарРыз
источник
3
Стиль С всегда раздражал меня. Быть последовательным!
Кристиан Манн
1

Все, что я могу сказать, это то, что если вы поклонник метода № 3, вас будут преследовать все средства форматирования кода IDE на земле.

Фил Коэн
источник
1

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

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

Но; самая важная вещь - последовательность. Используйте один или другой - никогда оба!

gablin
источник
0

Когда я впервые начал изучать программирование в 12 лет, я поставил скобки на следующую строку, потому что учебники Microsoft по кодированию такие же. Я также отступил с 4 пробелами TABS в то время.

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

Мин-Tang
источник
5
+1, -1. Почему бы вам НЕ делать отступы для вкладок, поскольку любой редактор может настроить длину вкладки на произвольную длину? В противном случае, вы заставите многих из нас, кто любит настоящие отступы в 8, проклинать ваш код.
Jé Queue
0

Существует 4-й вариант, который удерживает фигурные скобки, но не теряет места:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

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

AShelly
источник
9
... как и большинство программистов, которые бы подавились этим.
Jé Queue
4
Это кажется ужасным. Подумайте о дополнительных усилиях, которые вам придется пройти, если вы хотите вставить строку вверху или удалить верхнюю строку. Вы не можете просто удалить строку и двигаться дальше, вы должны помнить, чтобы заново вставить фигурную скобку.
Брайан Оукли
лол, это круто! :) лучше, чем первый стиль!
Nawfal
Видимо у него даже есть имя. Хорстман Сийл упоминается в википедии . Я работал с такой кодовой базой, это действительно неплохо в использовании.
AShelly
-1

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

Я лично предпочел бы 1-й метод.

Кроме того, я не получил то, что вы хотите показать по 3-му методу?

Разве это не неправильно? Например, рассмотрим ситуацию как ..

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

А что если кто-то захочет добавить еще несколько операторов в блок if ?

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

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();
Чанки патхак
источник
2
Еще хуже было бы, если бы кто-то пришел и сделал: if (you.hasAnswer ()) you.postAnswer (); иначе you.doSomething (); you.doSomethingElse (); - это рецепт для незначительных ошибок, которые глаз может легко
пропустить,
@FinnNk: Точно!
Chankey Pathak
2
Если кто-то хочет добавить еще одно утверждение, они могут сами поставить в скобки. Любой программист, достойный его соли, действительно должен это понять.
Роберт Харви
Я хотел сказать, что его третий метод неверен.
Chankey Pathak
3
@ Роберт Харви, я видел, как очень опытные программисты пропускают добавление скобок при модификации существующего кода. Я думаю, что проблема в том, что отступ является гораздо более сильным ключом к значению, чем фигурные скобки (особенно потому, что существует несколько стилей фигурных скобок), поэтому довольно просто пропустить пропущенную фигурную скобку, если отступ выглядит так, как вы ожидаете.
AShelly