Здравствуйте, _FRED_, Вы писали:
E>>И, что итересно, на распечатках такой код читается гораздо лучше защищаемого Макконелом стиля.
_FR>Чем же? Тем, что между "b();" и "a1();" три строчки или между "something();" и "while(...);" две?
Если чесно, то я первый раз вижу такую претензию к стилю оформления кода -- количество строк между двумя ветвями if-а. Она для меня не понятна, т.к. у меня в обычных функциях и так встречается по 5-6 пустых строк, которые разделяют логически связанные фрагменты кода.
А лучше GNU-тый стиль тем, что при беглом просмотре текста взгляд должен цепляться за "углы" кода, которыми являются:
* начало описания класса (т.е. ключевое слово class/struct);
* начало тела функции/метода;
* начало операторов или ветвей операторов (for, switch, while, do/while, if, else);
* декларации переменных.
GNU-тый стиль более явно, чем другие виденные мной стили, визуализирует "ступенчатую" структуру C-шной программы. Взгляд сразу цепляется за вещи вроде for, if, else и т.д. А вот если в коде есть строка:
} else {
то я с большой вероятностью ее вообще не замечу и просто решу, что у какого-то if-а вообще нет else.
_FR>Лично от меня в редакторе это скрывает, подчас, пятую часть, а то и четверть, кода.
У меня, обычно, тело функции не превышает одного экрана редактора даже с моим избыточным стилем программирования. Так что стремления экономить на количестве строк с единственной фигурной скобкой я понять не могу.
_FR>А в запарке написать вот так: _FR>
Здравствуйте, Курилка, Вы писали:
E>>и пока более удобного стиля не встречал. А критерий удобства у меня был, в общем-то, один: степень утомляемости зрения. Чем больше приходится возиться с кодом, чем больше приходится возиться с чужим кодом, чем больше приходится поднимать старый код, тем старше становишься, тем явственнее проступают отличия одного стиля от другого.
К>Только опятьже это твой опыт, я далеко не уверен, что он будет также применим к другим разработчикам.
Поскольку я ссылался на довольно старые соглашения о форматировании GNU, то это не только мой опыт.
И кроме того, я ответил на письмо, в котором ссылались на репутацию Макконелла. Книгу эту я не читал, сейчас открыл чтобы посмотреть, что он писал о форматировании и наткнулся на совершенно замечательный пассаж:
Однажды я написал программную реализацию алгоритма Data Encryption Standard (DES). Ну, на самом деле я писал ее не один раз, а около тридцати. При шифровании по алгоритму DES цифровые данные кодируются так, что их нельзя расшифровать без правильного пароля. Этот алгоритм шифрования так хитер, что иногда кажется, что он сам зашифрован. Моя цель состояла в том, чтобы файл объемом 18кб шифровался на IBM PC за 37 секунд. Первая реализация алгоритма выполнялась 21 минут 40 секунд, так что мне предстояла долгая работа.
25.5. Итерация, стр.590
(Макконелл С. Совершенный код. Мастер-класс / Пер.с англ. -- М.: Издателько-торговый дом "Русская редакция"; СПб.:Питер, 2005. -- 896 стр.)
Блин, у меня на IBM PC СЛАУ с почти сотней переменных быстрее считались методом итераций. И DES для него сложный алгоритм... Авторитет, однако. И эти люди запрещают ковыряться мне в носу...
K>>>а вообще особо большой разницы между стилями не вижу, если стиль применяется вменяемо (т.е. один по всей codebase продукта).
E>>Вообще-то это большой философский вопрос: стоит ли при развитии, например, 10-ти летнего проекта придерживаться выбранного 10-ть лет назад стиля, или же можно себе позволить в новых модулях придерживаться других стилей?
К>Ну если хочется иметь много веселья, то можно устроить "вавилонскую башню" из стилей. Положительных моментов в этом я особо не вижу.
Имхо, главное предназначение стиля -- сделать удобным для конкретных людей работу с кодом. Поэтому если команде не нравится какой-то стиль, то нужно отказаться от него в пользу более удобного для именно этой команды. А не быть догматиками и не молиться на кого-то там (будь то Макконелл или eao197).
Другое дело, что разработчику должен уметь следовать нескольким стилям. Равно как и программировать на нескольких языках.
К>Можно, конечно, перейти на "новый" стиль, но это надо будет перелопачивать старый без особой нужды, да и я не в курсе — можно ли плюсовый код без проблем переформатировать примерно так как это идея и эклипс делают...
А вот не надо старый код перелопачивать без надобности. Приходится вносить изменения в старый код -- пусть они будут оформлены как старый код. А новые модули пусть пишутся как удобно современной команде.
Что до автоматического форматирования текста программы, то я был несколько лет буквально шокирован обсуждением Java-вского стиля для одной из команд. Оказалось, что это форматирование меняет чуть ли не весь файл и это сказывается при коммитах в репозиторий и последующих попытках мержинга изменений из соседних веток. Имхо, один из случаев, когда маразм крепчает.
К счастью, в C++, да и в Ruby, такие автоформатеры не слишком распространены.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>И, что итересно, на распечатках такой код читается гораздо лучше защищаемого Макконелом стиля. _FR>>Чем же? Тем, что между "b();" и "a1();" три строчки или между "something();" и "while(...);" две? E>Если чесно, то я первый раз вижу такую претензию к стилю оформления кода -- количество строк между двумя ветвями if-а. Она для меня не понятна, т.к. у меня в обычных функциях и так встречается по 5-6 пустых строк, которые разделяют логически связанные фрагменты кода.
То есть просто пять-шесть пустых строк без единого не "пробельного" символа?
E>А лучше GNU-тый стиль тем, что при беглом просмотре текста взгляд должен цепляться за "углы" кода, которыми являются: E>* начало описания класса (т.е. ключевое слово class/struct); E>* начало тела функции/метода; E>* начало операторов или ветвей операторов (for, switch, while, do/while, if, else); E>* декларации переменных.
И не отрицаю: ведь и мой глаз, не обращая внимания на кавыки, "зацепляется" за else не хуже, чем за что-то другое
Так же не маловажно то, что else — это _всегда_ продолжение if и само по себе существовать не может, и это выражается так же в том, что else получается "сдвинутым" относительно объявления if-а (в моём случае — отступы в два пробела, ровно на один отступ — кавыка и пробел после неё).
E>GNU-тый стиль более явно, чем другие виденные мной стили, визуализирует "ступенчатую" структуру C-шной программы. Взгляд сразу цепляется за вещи вроде for, if, else и т.д. А вот если в коде есть строка:
} else {
E>то я с большой вероятностью ее вообще не замечу и просто решу, что у какого-то if-а вообще нет else.
Дело привычки.
_FR>>Лично от меня в редакторе это скрывает, подчас, пятую часть, а то и четверть, кода.
E>У меня, обычно, тело функции не превышает одного экрана редактора даже с моим избыточным стилем программирования.
Ключевое выделил. Три-пять процентов больших функций уже вызывает раздражение, так как смотреть на них, отлаживая\модифицируя\рафакторя приходится дольше, чем на "правильные" функции.
E>Так что стремления экономить на количестве строк с единственной фигурной скобкой я понять не могу.
Не "сэкономить", а убрать пустоты. Пустоты, большие достаточного, мне не нравятся
_FR>>очень легко с любым количеством лет стажа за плечами. E>Имхо, если стаж не приучает человека даже в запарке так не писать, то время было потеряно зря.
"Так" — это как? Не совершая ошибок? Стаж только моторику, автоматизм некоторых вещей нарабатывает. У кого-то это выражается в наборе дополнительных кавык при модификации блока. За меня блоки формируют сниппеты, так что затраты на кавыки нулевые. Но при быстром наборе необходимость поднять каретку на строку вверх, дойти до конца, поставить "{", потом вниз на две строки, в начало, поставить "}" и нажать Enter, потом подняться, добавить expression… Мне удобнее один раз поставить обе кавыки и не думать о вышеперечисленном вообще. Второй поинт: при чтении кода, когда кавыки, где возможно, опускаются, внутри-таки возникает ощущение: "а не ошибся ли тут автор, и не должна ли следующая строка быть в блоке выше"?
... << RSDN@Home 1 alpha 3 rev. 0>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
E>>>>И, что итересно, на распечатках такой код читается гораздо лучше защищаемого Макконелом стиля. _FR>>>Чем же? Тем, что между "b();" и "a1();" три строчки или между "something();" и "while(...);" две? E>>Если чесно, то я первый раз вижу такую претензию к стилю оформления кода -- количество строк между двумя ветвями if-а. Она для меня не понятна, т.к. у меня в обычных функциях и так встречается по 5-6 пустых строк, которые разделяют логически связанные фрагменты кода.
_FR>То есть просто пять-шесть пустых строк без единого не "пробельного" символа?
Да. См., например вот здесь функцию main. Далеко не образец изящного стиля, но для написанной за 10 минут функции вполне нормально.
_FR>Так же не маловажно то, что else — это _всегда_ продолжение if и само по себе существовать не может, и это выражается так же в том, что else получается "сдвинутым" относительно объявления if-а (в моём случае — отступы в два пробела, ровно на один отступ — кавыка и пробел после неё).
Существовать-то не может, но вот действия по if и по else находятся на одном логическом уровне. Поэтому смысла сдвигать вправо else я не вижу.
_FR>>>очень легко с любым количеством лет стажа за плечами. E>>Имхо, если стаж не приучает человека даже в запарке так не писать, то время было потеряно зря.
_FR>"Так" — это как? Не совершая ошибок?
Ошибки совершают все, не об ошибках речь. Просто опытный разработчик отличается от молодого тем, что:
a) попадают в условия запарки гораздо реже (то ли нюх на это дело вырабатывается, то ли человек учится предупреждать такие ситуации, то ли умудряется сваливать их на более молодых коллег);
b) попав в условия запарки суетятся и порят горячку гораздо меньше. Поскольку ну что тут такого? Ну запарка, ну очередная. Ну и что?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
даже не заметил, чем два варианта друг от друга отличаются).
А вот тайпдефы и юзинги, возможно, локальные функции (если бы были) могли бы сыграть роль.
Кстати, если результат "boost::bind(&hg::hg_info::hg_id, _1)" сохранить в переменной, то это тоже помогло бы.
Вот сравни:
auto statGroups = impl()->_model->get_groups();
for (auto it = statGroups.begin(); it != statGroups.end() ; ++it)
{
auto predicate = boost::bind(&hg::hg_info::hg_id, _1) == *it;
auto founded = std::find_if(impl()->_groups.begin(), impl()->_groups.end(), predicate);
if (impl()->_groups.end() == founded)
{
auto newGroup = std::find_if(newGroups.begin(), newGroups.end(), predicate);
add_group_widget(*it, newGroup == newGroups.end() ? *it : newGroup->hg_name);
}
}
и
auto statGroups = impl()->_model->get_groups();
for(auto it = statGroups.begin(); it != statGroups.end() ; ++it) {
auto predicate = boost::bind(&hg::hg_info::hg_id, _1) == *it;
auto founded = std::find_if(impl()->_groups.begin(), impl()->_groups.end(), predicate);
if(impl()->_groups.end() == founded) {
auto newGroup = std::find_if(newGroups.begin(), newGroups.end(), predicate);
add_group_widget(*it, newGroup == newGroups.end() ? *it : newGroup->hg_name);
}//if
}//for
так уже нагляднее, а всё потому что проблема того кода, что ты показал: длинные идентификаторы, и не решается она той или иной расстановкой скобок.
... << RSDN@Home 1 alpha 3 rev. 0>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Нэчер, Вы писали:
Н>Очень интересно, почему в JAVA (в отличии от C/C++) принято не переносить '{' на новую строку? Н>IMHO, жутко неудобно!
Потому что в отличие от C/C++ там есть общепринятый стандарт, которому большинство следует, что не может не радовать.
Вначале я сам матерился. Через месяц привык и это стал мой любимый стиль . Сильнее всего нравится то, что экономит место без ухудшения читаемости (я могу взглядом не напрягаясь охватить больше строчек).
А вообще — хорошо то, что этот стиль есть, и его практически все пользуют (кроме студентов, не удосужившихся прочитать code convention, блин).
Здравствуйте, eao197, Вы писали:
E>и пока более удобного стиля не встречал. А критерий удобства у меня был, в общем-то, один: степень утомляемости зрения. Чем больше приходится возиться с кодом, чем больше приходится возиться с чужим кодом, чем больше приходится поднимать старый код, тем старше становишься, тем явственнее проступают отличия одного стиля от другого.
Действительно, в споре рождается истина! Прочитав сообщение могу выразить чем мне нравится веренос фигурной скобки на новыу строку.
Это визуальное разделение логически разных блоков программы, т.е., например, условия и тела_условия.
Я ПОСТОЯННО между логически разными блоками в одной функции, которые при этом невозможно или не стоит выносить в отдельную функцию, порой занимающих 1-5 строк, разделяю пустой строкой.
E>А вот на распечатке, скорее, всего, взгляд за else не зацепится.
Я о том же — эта строка визуально не разделяет код. Думаю, т.к. человек визуальные обраы _гораздо_ лучше воспринимает, чем текст, то при беглом просмотре (то же, что посмотреть прищурившись, что текст виден не будет, а структура видна) — код с переносами скобок будет более читаем.
K>>а вообще особо большой разницы между стилями не вижу, если стиль применяется вменяемо (т.е. один по всей codebase продукта).
К сожалению, статистику по типам возникающих ошибок, при использовании тех или иных стилей, собрать не удастся... а жаль...
E>Вообще-то это большой философский вопрос: стоит ли при развитии, например, 10-ти летнего проекта придерживаться выбранного 10-ть лет назад стиля, или же можно себе позволить в новых модулях придерживаться других стилей?
Это можно использовать как инструмент, типа этот код мы писали давно, например от 1й версии кода или от сторонних разработчиков. Чтоб отличать свой и не свой код.
Здравствуйте, Plague, Вы писали:
P>Я ПОСТОЯННО между логически разными блоками в одной функции, которые при этом невозможно или не стоит выносить в отдельную функцию, порой занимающих 1-5 строк, разделяю пустой строкой.
+1
Если мне не изменяет мой склероз, нас этому учили еще на первом курсе, когда в качестве основного инструмента использовался Pascal.
E>>А вот на распечатке, скорее, всего, взгляд за else не зацепится.
P>Я о том же — эта строка визуально не разделяет код. Думаю, т.к. человек визуальные обраы _гораздо_ лучше воспринимает, чем текст, то при беглом просмотре (то же, что посмотреть прищурившись, что текст виден не будет, а структура видна) — код с переносами скобок будет более читаем.
+1
Причем это хорошо себя проявляет, когда приходится вставлять фрагменты кода в документацию.
E>>Вообще-то это большой философский вопрос: стоит ли при развитии, например, 10-ти летнего проекта придерживаться выбранного 10-ть лет назад стиля, или же можно себе позволить в новых модулях придерживаться других стилей? P>Это можно использовать как инструмент, типа этот код мы писали давно, например от 1й версии кода или от сторонних разработчиков. Чтоб отличать свой и не свой код.
Ух ты! А это идея
В C++ подобному разделению способствуют еще и разные стили CamelCase-ов или lower_case-ов. В Java с этим сложнее
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Plague, Вы писали:
P>>Это можно использовать как инструмент, типа этот код мы писали давно, например от 1й версии кода или от сторонних разработчиков. Чтоб отличать свой и не свой код.
E>Ух ты! А это идея E>В C++ подобному разделению способствуют еще и разные стили CamelCase-ов или lower_case-ов. В Java с этим сложнее
Здравствуйте, Plague, Вы писали:
K>>>а вообще особо большой разницы между стилями не вижу, если стиль применяется вменяемо (т.е. один по всей codebase продукта). P>К сожалению, статистику по типам возникающих ошибок, при использовании тех или иных стилей, собрать не удастся... а жаль...
Так Макконнелл и приводит разные исследования по статистике ошибок в понимании кода, когда код отформатирован тем или иным стилем.
Стили C++ и Java дают примерно одинаковые результаты по удобочитаемости и понимании кода.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>>Какие мысли будут?
E>Ну, если продолжать этот вечный священный спор, то:
E>1. Почему люди пишут такие длинные строчки? Они у меня, например, даже полностью в окно браузера не помещаются.
typedef'ить запаришься
E>2. Неужели выравнивание параметров функции под открывающую скобку для кого-то удобно? Даже, если получается что-то вроде: E>
E>call_function_with_very_long_name( first_argument,
E> call_another_function_for_second_argument( param1,
E> call_yet_another_function() ),
E> some_expression * as / third - argument );
E>
хз
E>3. Глагол find, насколько я помню, неправильный. Т.е. переменную, наверное, следовало бы назвать found. Или search_result.
Здравствуйте, Константин Л., Вы писали:
E>>1. Почему люди пишут такие длинные строчки? Они у меня, например, даже полностью в окно браузера не помещаются.
КЛ>typedef'ить запаришься
Здравствуйте, iZEN, Вы писали:
ZEN>Так Макконнелл и приводит разные исследования по статистике ошибок в понимании кода, когда код отформатирован тем или иным стилем. ZEN>Стили C++ и Java дают примерно одинаковые результаты по удобочитаемости и понимании кода.
да ну! три иф подряд + ошибочное выравнивание и пусть попробует тогда почитать
мне нужно читать неправильный код в котором не факт что скобки вообще сбалансированы поэтому использую только слева. А в работающий можно и не заглядывать
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, eao197, Вы писали:
КЛ>[]
КЛ>не подходит по одной простой причине — я люблю табы
Ты не поверишь, но я тоже. И в C++ вот такое же выравнивание я делаю с помощью табов.
А еще у меня табы выставлены в 3 символа -- сразу же видно, где кто-нибудь напортачит и смешает пробелы с табами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
