Здравствуйте, утпутуук, Вы писали:
У>Здравствуйте, Varavva, Вы писали:
V>>Кто как ставит { для цикла for? V>>В смысле в этой же строке или отдельно на следующей?
У>Отдельно У>
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Всеми разделяется убеждение, что вареные яйца при
употреблении их в пищу испокон веков разбивались с тупого конца; но дед
нынешнего императора, будучи ребенком, порезал себе палец за завтраком,
разбивая яйцо означенным древним способом. Тогда император, отец ребенка,
обнародовал указ, предписывающий всем его подданным под страхом строгого
наказания разбивать яйца с острого конца. Этот закон до такой степени
озлобил население, что, по словам наших летописей, был причиной шести
восстаний, во время которых один император потерял жизнь, а другой —
корону
Здравствуйте, Varavva, Вы писали:
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Хотя если в скобках одна строчка (как в if/else этом коде) то скобки вообще не ставлю.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда "{" на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
В студенчиские годы ставил { на той же строке, и был уверен что только так удобно и правильно. Пришел на первую работу,
а там у них на следующей строке ставят и вообще есть внутренний стандарт, который обязывает ставить на следующей строке.
Не представляете как меня это раздражало, но где-то через месяц вдруг привык и стало казаться что ставить "{" надо именно на следующей строке и тлько так удобно и правильно.
Потом сменил я работу, а у них по внутреннему стандарту положено на той же строке ставить.. Как меня это раздражало! Но через две недели привык.
Перешел на другой проект, а там опять на следующе строке ее ставят, ужас!!!
После нескольких таких итераций стало пофигу, к любому стилю привыкаешь где-то за неделю.
Это же относится к вопросу, какого размера делать отступ, пробелы или табуляция, CamelCase или snake_case, и тд.
Главное, придерживаться одного стиля во всем проекте, для этого в начале проекта желательно договориться всей командой о стиле, который будет меньше всего раздражать комманду.
Если надо править уже существующий старый код, то стоит оставить тот стиль в котором он написан.
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Всегда ставлю на этой же строке. Сокращает число строк, больше помещается на экран. Ничего смешного не вижу и каких-то преимуществ ставить { на отдельной строке тоже не вижу.
Здравствуйте, T4r4sB, Вы писали:
TB>А почему "} else" не одной строке не пишешь? Это же никак не портит.
Полностью испортит. "else" должно быть точно под соответствующим "if"
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
пишу часто на той же строке, если и закрывающая скобка тоже на этой же строке (то есть внутри 1-2, максимум 3 стэйтмента)
ради экономии строк и объектов внимания
for( int i=0; i<50; i++ ) { if( i%2 == 0 ) Console.WriteLine("Гляди-ка, чётное: "+i); }
// или так чаще:for( int i=0; i<50; i++ ) { Console.WriteLine( (i%2==0 ? "Чётное" : "Нечётное") + ": " + i); }
Властитель слабый и лукавый,
Плешивый щеголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
Здравствуйте, Varavva, Вы писали:
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Во многих стилях кодирования запрещено использовать for и if без { }. Цикл for или if с телом из одной строчки и с { на новой строке выглядит блевотно:
if (err != 0) {
throw std::runtime_error("bloody hell!");
}
vs
if (err != 0)
{
throw std::runtime_error("bloody hell!");
}
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Varavva, Вы писали:
V>>Кто как ставит { для цикла for? V>>В смысле в этой же строке или отдельно на следующей?
A>Я ставлю на следующей строке — чтобы открывающая и закрывающая скобка стояли друг над другом.
A>
A>for( int i=0 ; i<10 ; i++ )
A>{ printf("сам дурак!\n"); // <-- скобка и первый оператор на одной строке
A>}
A>
а я так:
for( int i=0 ; i<10 ; i++ )
{
printf("сам дурак!\n"); // <-- скобка и первый оператор на разных строчках, оператор без оступа
}
Во первых это не красиво. Блоки с одной сточкой внутри будут отличаться от блоков большего размера. В однострочных {} будут сливаться, в больших блоках будет разрыв, КМК, это создает визуальный мусор
if (!status)
{ panic("fail");
}
vs
if (!status)
{ log(status, "error message");
panic("fail");
}
К тому же, легко допустить следующую ошибку, допустим изначально было:
if (!status)
{ panic("fail");
log(status, "error message");
}
мы поменяли строчки местами, но забыли про {
if (!status)
log(status, "error message");
{ panic("fail");
}
код скомпилировался, но теперь panic вызвыается всегда
Здравствуйте, CreatorCray, Вы писали:
CK>>лишняя строка делает его лучше? CC>Да, читабельнее.
Почему?
Мне это не нравится, т.к. я привык отделять блоки кода друг от друга пустыми строками
status = api_call_foo(...)
if (!status) {
panic("foo failed")
}
do_smthng_with_foo()
//< пустая строка отделяет два блока кода
status = api_call_bar(...)
if (!status) {
panic("bar failed")
}
сравни с
status = api_call_foo(...)
if (!status)
{
panic("foo failed")
}
do_smthng_with_foo()
//< теряется на фоне кучи строк содержащих только { или }
status = api_call_bar(...)
if (!status)
{
panic("bar failed")
}
Здравствуйте, T4r4sB, Вы писали:
TB>Почему? Оно и так прекрасно видно издалека.
Кто-то считает, что и с "{" в конце строки начинающейся "for" все прекрасно видно издалека
TB>"} else" должно быть точно под соответствующим "if"
Нет, "}" должна быть под "{", а "else" под "if"
При сохранении стиля предлагаемого предыдущим оратором, с которым я полностью согласен, разумеется не имея возможности и желания навязывать именно этот стиль.
Здравствуйте, b0r3d0m, Вы писали:
B>Как там, в 1980?
В 1980 в Москве прошли Олимпийские игры. А программисты не спорили,что лучше: begin/end или {} и на какой строке что писать. Они просто работали. И, быть может, именно поэтому софт, написанный в те годы, работает десятилетиями?
Здравствуйте, Varavva, Вы писали:
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
скобцам не понять.
меня напрягает скроллить код изза перенесённых скобок. уж лучше всё видеть на одном экране, а не ползать.
также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору.
Здравствуйте, b0r3d0m, Вы писали:
B>Меня больше бесит отсутствие в большинстве Lisp'ов мега-закрывающей скобки. А то в некоторых (например, в Clojure) ещё и на одной строчке принято закрывать все накопившиеся скобки. Потом сиди и разбирай, куда тебе свою впихнуть надо, или откуда убрать ненужную:
Эту проблему помогает решить режим редактирования в котором манипулирование совершается не на уровне отдельных символов скобок и т.п., а на уровне узлов синтаксического дерева: https://www.youtube.com/watch?v=D6h5dFyyUX0
Здравствуйте, anonymouse2, Вы писали:
A>Хотя если в скобках одна строчка (как в if/else этом коде) то скобки вообще не ставлю.
Вот именно так и я пишу, хотя в одну строчку с if никогда не делаю. И почти всегда ставлю скобки в if. Во-первых, разношу по строчкам, чтоб было где ставить точку останова. А ставлю скобки, чтоб потом со вставкой например логирования не делать этого.
А вот в чём логика ставить пробел между if и '(', но не ставить между функцией и '('?
Вот я понимаю тех кто ставит и там и там, или не ставит нигде. :/
Здравствуйте, neFormal, Вы писали:
V>>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это. F>скобцам не понять. F>меня напрягает скроллить код изза перенесённых скобок. уж лучше всё видеть на одном экране, а не ползать. F>также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору.
Задачу устранения визуального мусора можно решить на стороне редактора. Например не показывать фигурные скобки, а также ;.
В Emacs это решается через оверлеи (сам код вообще не меняется, меняется только отображение):
Этот код можно редактировать, но для полноценной поддержки редактирования нужно добавить отслеживание того, чтобы пользователь не мог случайно удалить скобки (они ведь есть на самом деле, как тот суслик), и чтобы гарантировалось их автоматическое расставленние. Под капотом можно использовать стиль который принят в проекте.
Здравствуйте, Varavva, Вы писали:
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
А вообще от языка зависит. Если операторные скобки — это еле видимые фигурные скобочки, то приходится делать лишний перенос и ставить одну на другой. Потому что иначе ну в натуре не видно, где блок начинает и кончается. В языках, где блок завершается жирным словом end (Паскалоиды, Луя), нет необходимости в переносе. Сразу издалека видна пара if-end, или for-end.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, alpha21264, Вы писали:
A>>Я ставлю на следующей строке — чтобы открывающая и закрывающая скобка стояли друг над другом. A>>
A>>for( int i=0 ; i<10 ; i++ )
A>>{ printf("сам дурак!\n"); // <-- скобка и первый оператор на одной строке
A>>}
A>>
EP>В этом варианте неудобно менять строки местами, копировать и т.п. — так как мешается первая скобка.
Я знаю. Но программы гораздо чаще читаются, чем пишутся.
TB>Извини, но у тебя блевотный стиль. Я переживу и скобки отдельно, и скобки на старой строке, но не это.
У меня дети сами, без посторонних подсказок, вышли на этот вариант. Значит, в нём что-то есть хорошее.
(Только отступы чуть другие — 2 перед {} и 2 после них)
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, alpha21264, Вы писали:
A>>Я знаю. Но программы гораздо чаще читаются, чем пишутся.
CK>Так оно и выглядит говняно. Да еще и inconvenient as fuck.
Вот уже детский сад пошёл.
Как оно выглядит?
Обосновать можешь?
Лучше его делает не строка, а четкое обозначение тела программы, расположенного между скобками. Благодаря тому, что закрывающая скобка расположена точно под открывающей.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, rumia, Вы писали:
R>А вот в чём логика ставить пробел между if и '(', но не ставить между функцией и '('?
Чтобы сразу было видно, где оператор языка, а где вызов функции. Я ещё после assert пробел ставлю, так как он, во-первых, не функция, а макрос, а во-вторых, фактически заменяет отсутствующую нужную фичу языка — проверку выполенения условия в точке.
может звучать странно, но в разных языках — по разному. например, в шарпе скобку ставлю в следующей строке, а вот в js и swift — на той же. как то естественно получается так, особо даже и не парюсь над этим. вероятно, в шарпе так получилось в силу многолетней привычки, да и решарпер по моему больше любит, когда скобку на следующую строку переводят. вот и меня он к этому приучил. а в свифте почти все примеры кода, что я видел, используют второй вариант, то есть открывающая строчка на одном уровне с циклом или ифом. возможно, что так получилось еще и из-за того, что swift придумал замечательную вещь, от которой довольно сложно избавиться, когда пишешь на том же шарпе. в swift в циклах или ифах не обязательно использовать круглые скобки с условиями, да и точку с запятой тоже не обязательно ставить в конце строчки с кодом. что хоть не намного, но упрощает процесс разработки и код хочется писать за меньшее время. а потому и скобку ставишь на том же уровне, что и условие.
но религиозный вопрос, как лучше — давно отпал. по большому счету по фигу.
Здравствуйте, neFormal, Вы писали:
N>>Скроллить нужно только в кривых редакторах, которые вместо заворота строки показывают её обрезанной. N>>Может, они хороши для показа табличек в тексте, но не для кода.
F>враппинг тут ни при чём. код именно вертикально вытягивается, что не несёт никакого смысла.
Мало какому коду это реально проблемно (а если так — часто у него есть собственно проблемы перегруженности). Я часто вставляю пустые строки для логического разделения частей кода. Зато то, что '{' сама бросается в глаза, и на том же уровне, что '}', резко облегчает парсинг кода по блокам глазами.
F>>>также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору. N>>Это к чему? F>к тому, что скобки не нужны,
Я не знаю, как вообще комментировать эту чушь. Мы же вроде не о Python или Haskell говорили?
F> поэтому прятать их в египетском стиле — это легко, приятно,
Они неизбежны, и прятать их — маленькое, но зло.
F> исправляет прикус и не сушит попку твоего малыша.
А зубы становятся белыми и пушистыми. Спасибо, проходили.
Зависит от языка. В C++ ставлю на отдельной строчке, в JS -- на той же.
Меня больше бесит отсутствие в большинстве Lisp'ов мега-закрывающей скобки. А то в некоторых (например, в Clojure) ещё и на одной строчке принято закрывать все накопившиеся скобки. Потом сиди и разбирай, куда тебе свою впихнуть надо, или откуда убрать ненужную:
Здравствуйте, Varavva, Вы писали:
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Переходи на Фортран, и этот вопрос перестанет тебя волновать сразу и на всю жизнь.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, T4r4sB, Вы писали:
TB>>А почему "} else" не одной строке не пишешь? Это же никак не портит. P>Полностью испортит.
Почему? Оно и так прекрасно видно издалека.
> "else" должно быть точно под соответствующим "if"
"} else" должно быть точно под соответствующим "if"
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, T4r4sB, Вы писали:
TB>>Почему? Оно и так прекрасно видно издалека. P>Кто-то считает, что и с "{" в конце строки начинающейся "for" все прекрасно видно издалека
За ней над взглядом бежать. А елси возле скобки — вот он, рядом.
TB>>"} else" должно быть точно под соответствующим "if" P>Нет, "}" должна быть под "{", а "else" под "if"
С первым согласен, со вторым нет, не вижу ну ни малейшего смысла. Ну разве что если оплата зависит от числа строк.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
А мне правой рукой попу подтирать неудобно, но я же не создаю темы с названием "П"
Здравствуйте, Икс, Вы писали:
V>>Кто как ставит { для цикла for? V>>В смысле в этой же строке или отдельно на следующей?
V>>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Икс>А мне правой рукой попу подтирать неудобно, но я же не создаю темы с названием "П"
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Икс, Вы писали:
V>>>Кто как ставит { для цикла for? V>>>В смысле в этой же строке или отдельно на следующей?
V>>>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Икс>>А мне правой рукой попу подтирать неудобно, но я же не создаю темы с названием "П"
M>С этим не в КСВ, а в просто СВ
Удобнее в МЖ
Здравствуйте, T4r4sB, Вы писали:
TB>А почему "} else" не одной строке не пишешь? Это же никак не портит.
Мне лично в таком варианте напрягает как зачастую else становится ровно по середине под }
if (true) {
...
for (int i=0;i<10;i++) {
...
} // и ниже else
} else {
...
}
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, alpha21264, Вы писали:
A>>Я знаю. Но программы гораздо чаще читаются, чем пишутся.
Pzz>Если написать printf на отдельной строчке, программу не станет сложнее читать.
Не факт, кстати. Обычно заголовок ифа вместе с его содержимым — это единая логическая единица. И когда она монолитна без пропусков, то глазом проще увидеть, что это единая логическая единица.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, chaotic-kotik, Вы писали:
CK>clang-format так не отформатирует CK>напрямую запрещено стилем кодирования на работе (считаю что хорошая идея)
Это непринципиальные частности, читаемость твоего варианта они не улучшают и вариант
if (err != 0)
{
throw std::runtime_error("bloody hell!");
}
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, alpha21264, Вы писали:
A>>Я знаю. Но программы гораздо чаще читаются, чем пишутся.
Pzz>Если написать printf на отдельной строчке, программу не станет сложнее читать. Но зато ее станет проще писать.
Станет сложнее читать. Лишняя строчка потратится. А это значит, что в экран влезет меньше текста.
CK>напрямую запрещено стилем кодирования на работе (считаю что хорошая идея)
Это уже похоже на yoda conditionals — да, немного повышает безопасность (будущих изменений), но при этом несоизмеримо бьёт по другим параметрам (лаконичность).
Yoda conditionals используете?
CK> //< теряется на фоне кучи строк содержащих только { или }
CK>
Не теряется, тем более если включено отображение непечатаемых символов.
И при твоём подходе несколько строчек с } не отделённые пустыми строчками всё равном могут быть (несколько уровней в глубину).
У простых структур (без конструкторов) тоже оставляю скобку на той же строке.
V>В смысле в этой же строке или отдельно на следующей?
Смысл всегда в оптимальной читабельности.
Скобка, оставленная на той же строке, говорит мне, что речь пойдёт о простом сниппете.
V>Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Это ты не пробовал читать исходники программ, распечатанные на "бесконечной" ленте матричного принтера.
Вот это было действительно удобно.
Тут никакая экономия строк не требовалась.
А 2-3 десятка строк на экране — это заведомо нечитабельно вовсе.
Т.е., эти все трюки можно списать на попытки разместить перед глазами больше осмысленных строк текста.
Здравствуйте, neFormal, Вы писали:
F>скобцам не понять. F>меня напрягает скроллить код изза перенесённых скобок. уж лучше всё видеть на одном экране, а не ползать. F>также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору.
Фигово код написан, если для понимания листать надо. Понимание, что делает функция приходит пошагово и блочно. Вот этот цикл отделяет то от этого, вот это условие — когда то-то. Невозможно обхватить разумом и понять целую страницу напичканную вызовами других функций.
Здравствуйте, Varavva, Вы писали:
V>Фигово код написан, если для понимания листать надо.
да, скобки не нужны. только место отъедают.
V>Понимание, что делает функция приходит пошагово и блочно. Вот этот цикл отделяет то от этого, вот это условие — когда то-то. Невозможно обхватить разумом и понять целую страницу напичканную вызовами других функций.
я код читаю наискосок. и всё понятно.
потому что хороший код можно так прочитать, а вот в плохой приходится вчитываться.
Здравствуйте, neFormal, Вы писали:
V>>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
F>скобцам не понять. F>меня напрягает скроллить код изза перенесённых скобок. уж лучше всё видеть на одном экране, а не ползать.
Скроллить нужно только в кривых редакторах, которые вместо заворота строки показывают её обрезанной.
Может, они хороши для показа табличек в тексте, но не для кода.
F>также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору.
Здравствуйте, netch80, Вы писали:
N>Скроллить нужно только в кривых редакторах, которые вместо заворота строки показывают её обрезанной. N>Может, они хороши для показа табличек в тексте, но не для кода.
враппинг тут ни при чём. код именно вертикально вытягивается, что не несёт никакого смысла.
F>>также это минимизация визуального мусора, потому что скобки кодеру не нужны, они нужны компилятору. N>Это к чему?
к тому, что скобки не нужны, поэтому прятать их в египетском стиле — это легко, приятно, исправляет прикус и не сушит попку твоего малыша.
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Это вопрос стиля кода. Обычно в проекте надо либо ставить { на той же строке везде, либо на следующей также везде.
Сложностей нет, привыкаешь к любому стилю. Может пару недель придётся потратить на привыкание, если используешь только один стиль.
А текущем проекте { скобочку надо ставить на той же строке. Код, где скобка ставится на следующей строке, меня сейчас раздражает. Но раньше было наоборот.
Здравствуйте, cures, Вы писали:
C>Здравствуйте, rumia, Вы писали:
R>>А вот в чём логика ставить пробел между if и '(', но не ставить между функцией и '('?
C>Чтобы сразу было видно, где оператор языка, а где вызов функции.
Кха... Это редактор и так подсветкой показывает.
И даже если не показывает, операторов не так много — их и так знаешь.
Здравствуйте, neFormal, Вы писали:
N>>Мало какому коду это реально проблемно F>ты думаешь об одной ф-ции, а я про несколько ф-ций на одном экране.
Я думал, я тут один сижу в основном в 25x80. Но даже в этом случае количество ситуаций, когда надо сверять несколько соседних кусков — крайне мало, и в основном это случаи конфликтного мержинга патчей.
F>>>к тому, что скобки не нужны, N>>Я не знаю, как вообще комментировать эту чушь.
F>вежливость зашкаливает.
Воистину так. А вот писать безусловную чушь — невежливо, ибо ведёт к бессмысленным оффтопикам.
Здравствуйте, RiNSpy, Вы писали:
RNS>А почему пробелы такие? Лучше же вот так: RNS>
RNS>for (int i = 0; i < 10; i++)
RNS>
А я пишу вызовы функций без пробелов: sqrt(x), но заголовки циклов и условий с пробелами: if ( a > 0 ) {...}, for ( int i = 0; i < count; ++i ) {...}. Так кажется читабельнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Задачу устранения визуального мусора можно решить на стороне редактора. Например не показывать фигурные скобки, а также ;.
прекрасно! спасибо
очень оригинальное извращение
EP>Этот код можно редактировать, но для полноценной поддержки редактирования нужно добавить отслеживание того, чтобы пользователь не мог случайно удалить скобки
Здравствуйте, neFormal, Вы писали:
EP>>Задачу устранения визуального мусора можно решить на стороне редактора. Например не показывать фигурные скобки, а также ;. F>прекрасно! спасибо F>очень оригинальное извращение
Я видел на эту тему разбавление CamelCase'а виртуальными подчёркиваниями (link).
EP>>Этот код можно редактировать, но для полноценной поддержки редактирования нужно добавить отслеживание того, чтобы пользователь не мог случайно удалить скобки F>да, вот это-то и пугает больше всего.
Да, это самая сложная часть, но вполне реализуемая.
В конце концов можно при редактировании включать скобки (автоматом), а при просмотре выключать. Хотя конечно лучше не скакать между режимами.
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей?
Всегда уважаю принятый в команде стандарт кодирования во всех подобных вопросах.
Потому что надо же хоть в чём-то следовать этому самому стандарту кодирования.
Так лучше буду следовать ни на что не влияющим правилам, и поставлю скобку, как просят, чем буду, например, заниматься эквилибристикой при выходе из вложенного for, потому что, типа, "у нас множественный return запрещен, и goto тоже запрещен".
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for? V>В смысле в этой же строке или отдельно на следующей? V>Мне ужасно неудобно и плохо читаемо, когда { на той же строчке. Какие плюсы такого написания? Текст программы сокращается? Ну смешно же это.
Самые крутые программеры вообще пишут без всяких {
Здравствуйте, Varavva, Вы писали:
V>Кто как ставит { для цикла for?
Всё зависит от принятого code style в проекте/команде. А они могут меняться от проекта к проекту.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Стоит заговорить про плюсы, так плюсы говно, трогай за питон, шарб, жабу, память течет, указатели нипанятны, долго компилицца.
А как до дела доходит так оппа, все на плюсах пишуть.
Парадокс
Здравствуйте, Sheridan, Вы писали:
S>Стоит заговорить про плюсы, так плюсы говно, трогай за питон, шарб, жабу, память течет, указатели нипанятны, долго компилицца. S>А как до дела доходит так оппа, все на плюсах пишуть. S>Парадокс
Не все. Я, например, не пишу на плюсах. Правда, я и не обзываю их по-всякому. Они под рукой на всякий случай. В нашем проекте пара сотен строк на них есть. Иногда, кроме как на них — никак.
Скобки есть, опять же, не только в плюсах.
Здравствуйте, Hobbes, Вы писали:
H>А это как можно обосновать?
Якобы, чтобы добавить в начало захват ресурса, а в конец его освобождение, и не получить сюрпризов.
Вроде как из широко применяемых языков должно быть применимо только к С, т.к. в С++ есть RAII, в других языках — finally.
Но сторонники правила одного возврата предпочитают почему-то это правило, а не правильное управление ресурсами.
H>И как с этим жить? Записать значение в переменную, а потом переменную возвращать? Но так совсем плохо получается.