Как стать автором
Обновить

Комментарии 73

Лучше — как удобнее
А почему?
Мне так удобней, дело привычки наверно.
меньше строк занимает, больше кода влазит на страницу, легче читать
а вот мне нравится

if (condition)
{

}
else
{

}

Да, так я трачу еще 2 лишних строки. Возможно это не так рационально, но мне нравится.
Ну я же просил :-)
упс, искренне извиняюсь, не заметил…

А по сабжу — мне лично больше нравится 2-ой вариант. Он более структурирован и понятен.
В 1-ом слишком нагруженная строчка выходит
} else {
Пишу также, а из 2х предложенных вариантов предпочтение падает на 2й!
выбираю ваш вариант
Не две, а три.
Зато по открывающимся и закрывающимся скобкам очень хорошо видна вложеность
Делаю точно так же. Глазу всегда понятно где что начинается и заканчивается + в редакторе легче работать.
Мне такой больше нравится!
Когда блок отрицательного условия не нуждается в комментарии, я пишу } else {.
Когда же необходимо пояснить каждый блок, то выходит так:

// comment
if (cond) {
    // actions
}

// comment
else {
    // actions
}
Мне больше нравится:

if (cond) { // comment
    // actions
}
else { // comment
    // actions
}
Имхо очень плохо, когда condition нуждается в комменте. Лучше вместо такого:
// Проверям не лето ли сейчас…
if(month > 5 && month < 9) {
   //…
}

Написать что-то вроде
if(nowIsSummer(month)) {
}

И глазам проще, и при просмотре кода мы уже не отвлекаемся на зачастую страшные условия…
Второй вариант. Ключевое слово else отвечает слову if, поэтому у них должны быть одинаковые отступы — код так лучше воспринимается. Отступы должны быть везде одинаковые — скажем 4 пробела, тогда очень легко читать код и фильтровать внутренние блоки.
Первый вариант, так я экономлю больше строк, следовательно больше кода вижу без скроллинга.
Просто ненавижу код, в котором на один экран влезает мало смысла.

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

на самом деле про экран маразм… размер метода должен быть таков чтобы его можно было единомоментно охватить мозгом (за исключением особых случаев типа хитрых мат методов и прочего)
> какой у вас язык?
Perl, мигрирую на Java
> какой длины у вас средняя строчка?
Сложно сказать, символов 15-25 наверное.

> единомоментно охватить мозгом
Сколько строчек может единомоментно охватить Ваш мозг?

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

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

На вскидку, штук 50.
if (flag)
.........{
..................action();
.........}
else
.........{
..................action2();
.........}

Хотя так стурктура получается слишком широкой.
Да уж. Два-три вложенных ифа — и читать код станет невозможно.
Мне как раз таки очень удобно на широченном мониторе.
А каково другим это читать? Хорошо, если писатель и читатель — один человек. А у нас, например, девелоперов много, платформы разные, не всегда удобно читать широченный код. Стараемся укладываться с 80 символов. Ваш способ явно непригоден для такой разработки.
Да я и не спорю — у меня в основном разовые небольшие проекты, так, в помощь при работе
я использую вариант 2, мне кажется он более удобен
1 вариант неудобен при длинных ветвлениях else if, ну а вообще не рекомендую его использовать.
Я предпочитаю первый вариант, потому что видна логическая связь else с iа

к примеру два подряд идущих цикла не связанны, поэтому второй начинается с новой строки, а if-else это единая конструкция.

Все это — мое мнение
> логическая связь else с IF

punto switcher балуется *sorry*
Я за первый вариант. Логика:

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

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

Соответственно, код получается более читабельным.
То есть, конечно, второй вариант я имею в виду, не первый.
Первый вариант. И упомянутые выше стандарты Java. И с толку не сбивает — сразу видно else-конструкции. Аналогично на одной строке всегда }catch(...){.
new { true: function(){
// when true
}
, false: function(){
// when false
}
}[ condition ];

=]
pastebin.ru/300319
pastebin.ru/300320
Вообще говоря, у любого форматирования есть свое логическое обоснование. В частности, в основе варианта 1, известного также как 1TBS (One True Brace Style), лежит следующая идея: конструкции, позволяющие вставку строк кода, располагаются на разных строках, тогда как конструкции, не позволяющие этого — на одной.

В Вашем случае, вариант 2 является неким смешением стиля Олмана (приверженцев которого Вы просили обойти топик стороной) и 1TBS, что, наверное, не очень хорошо.
Да, да, да! Это оно :-) Я очень давно читал про это и забыл уже. Тщетно пытался найти в гугле, перед тем как постить сюда, но совершенно забыл все кейворды, по которым можно было бы выйти хотя бы на статью из википедии: en.wikipedia.org/wiki/Indent_style
Спасибо вам!
// php

if (condition):

else:

endif;
Это вы как бы выделились, или действительно используете данный стиль повсеместно?
а вы не пользуетесь? ну и лохи!
Таким стилем на PHP удобно форматировать код в шаблонах, макетах, в общем там, где php логика отображения идет вперемешку с html, а в контроллерах и моделях, конечно, обычные скобки :) согласно приянтым в организации или комьюнити соглашениям :(
Предпочитаю данный способ использовать в шаблонах.
Скорее первый (хотя у меня нет четкого понятия стиля — вроде и PEAR, а вроде и что-то еще намешано)
Эх вы, PEAR… Это гораздо более старый стиль, называемый K&R — его, если верить вики использовали ещё в книге 1978 года те, в честь кого он назван — Кёрниган и Ритчи.
Выше правда уточнили про 1TBS — за это не поручусь, но в вики (по ссылке в этом комментарии) та же информация.
Тогда я полностью следую стилю авторов Си даже в таких языках, как PHP (единственное искючение — питон, кто знает — тот поймет) ^_^
Аналогично, хоть и пишу на Java. Правда для дотнета визуал студия не даёт сохранить стиль и принудительно переносит скобки.
Раньше постоянно использовал 1TBS. Сейчас постоянно использую стиль Олмана.
Второй вариант по мне как-то не айс.
Вот кстати очень хотел бы услышать, что послужило причиной перехода.
Олман всех делает по чтению кода с распечаток… ну и некоторым (например мне) его гораздо удобнее читать с экрана
Участвовал некоторое время в проекте где все использовали Олмана. Попробывал, понравилось.
+ да. Согласен с тассом. Олмана читать удобнее.
Окей, а вот такой тогда вопрос, коллеги:
как вы форматируете if в случае длинного-предлинного условия, которое для читабельности неплохо бы разбить на несколько строк? (интересует отступ)
я отступаю до скобки (чтобы условия были друг под другом)
Так и оставляю одной строкой. Проскролить не лень, а для меня целая строка читается лучше, чем разбитая на куски.
первый вариант, так как уже упоминали Java coding conventions, а еще потому, что когда условия на других языках пишешь:

if condtion
some_actions
else
some_actions
end

аналогия, что else должен занимать одну строчку
НЛО прилетело и опубликовало эту надпись здесь
if (a < 0) {

} else if (a == 0) {

} else if (a > 0) {

}
Открывающая скобка получается всегда на одной строке с условием (много else для наглядности). А код от края отделяется отступом. Минимум строк, максимум наглядности. По мне так.
if (a < 0) {

} elseif (a == 0) {

} elseif (a > 0) {

}
о да, целый пробел сэкономил…
а в некоторых языках можно аж elif писать…
тут не только пробел, но и другая синтаксическая конструкция, чуть быстрее работать будет компилятор (бинарный код наверное все-таки соптимизируется) или интерпретатор
Использую первый вариант, потому что при беглом чтении кода для меня он более цельно воспринимается, как одна конструкция. А когда в коде натыкаюсь на второй вариант, то непроизвольно глазами пробегаю наверх, как будто чтобы убедиться, что if присутствует, его не забыли.
if(condition) { //comments
....code();
....here();
} else { //comments
....code();
....here();

}
Вопрос в удобстве восприятия каждого человека в отдельности. Лично я предпочитаю пользоваться вторым вариантом. На работе, в кодах, часто вижу и первый и второй варианты — в принципе нисколько не напрягает чтение. Однако, когда сам пишу, то уже машинально расставляю операторы вторым вариантом, а иногда доходит до того, что перед тем как написать условие, на автомате набиваю заготовку этого блока.
потому в руби используются begin и end, чтобы не было разногласий в офрмлении ;)
В одной книге в своё время прочитал, что хорошему программисту совершенно всё равно какое форматирование используется, он код и так и так поймёт(что за книга не помню :) ). Так что тут дело привычки.
Как принято в проекте так и приходится писать, да и при использовани фреймворков, CMS и т. п., стараюсь следовать соглашениям конкретного продукта, (бывают, правда, проблемы выбора, когда «скрещиваешь зенд с чем-нибудь :) ) Ну а когда с нуля, то первый вариант, правда давно уже такого не было
1-й вариант, для восприятия приятнее и как-то конструкция чувствуется что-ли. Моя привыкла к варианта 1.
НЛО прилетело и опубликовало эту надпись здесь
1 вариант
потому что /usr/src/linux/Documentation# less CodingStyle

Note that the closing brace is empty on a line of its own, _except_ in
the cases where it is followed by a continuation of the same statement,
ie a «while» in a do-statement or an «else» in an if-statement, like
this:

do {
body of do-loop
} while (condition);

and

if (x == y) {

} else if (x > y) {

} else {

}

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории