S>Ребята, которые в 16 веке потратили время и силы на выработку принципов вёрстки, уважительной к читателю. Если что, Кнутовский алгоритм из TeX растёт корнями как раз оттуда.

Это, конечно, классно и очень правильно, но применимо только к dense-тексту. Если б код писали так, что СРЕДНЕЕ количество непустых символов в строке было 66-72, программы стали бы намного короче в плане строчек

J>И всё в одну строку??

Ага. Так удобнее, чем когда нафиг ненужная шапка функции занимает 10 строк, забивая собой всю логику.

_>Не знаю откуда пошла такая мода в шарпах, котлине и джаве, это при вызове, каждую переменную писать на отдельной строке

Зато я знаю. Дело в том, что сделать автоформаттер, который делает нормальный reflow, — довольно сложная задача, требуется очень хорошо подумать. К тому же асимптотическая сложность известного мне алгоритма reflow — O(N^3). Первые автоформаттеры обычно работали целиком над файлом, и при такой сложности на больших файлах тупили неимоверно. Соломоново решение — а нафиг надо, сделаем тупейший алгоритм, так что каждый аргумент на своей строчке. И плевать, что это делает код нечитаемым. Ведь задача поставлена — сделать автоформаттер, а не "сделать так, чтобы было удобно читать код".

Здравствуйте, SkyDance, Вы писали:

SD>"Но он же не ветеринар!" (С) анекдот.

SD>Да, книжная строка, в которой 72 символа, и где-то 60-64 непустых в среднем, вполне комфортны. Однако агрессивные стадА любителей под одну гребенку всегда требуют, чтобы гребенка была их. А значит, для "{" и "}" требуется отдельная строчка, и написать if (a > 1) x++ следует не в одну, а в 3 строки (или 4, если, как нравится многим, перед if требуется оставить пустую строку):

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

А if (a > 1) x++; банально не позволяет поставить точку останова на ветке, когда условие выполнилось. Покажи мне IDE с отладчиком под плюсы, где на таком выражении можно поставить брикпоинт так, чтобы он срабатывал только при выполнении условия, и без гемора по заданию доп условий срабатывания этого брикпоинта. Такое годно только для тривиальнейших случаев типа такого:

          iterator begin ()       { return m_map.begin (); }
    const_iterator begin () const { return m_map.begin (); }
    const_iterator cbegin() const { return m_map.cbegin(); }

          iterator end   ()       { return m_map.end   (); }
    const_iterator end   () const { return m_map.end   (); }
    const_iterator cend  () const { return m_map.cend  (); }

SD>

SD>if (a > 1)
SD>{
SD>  x++;
SD>}
SD>

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

if (cond==1)
    ++x;

else if (cond==10)
    x += 2;

else if (cond==11)
    x += 25;

else
    x = 100500;

Но вообще в скоупе тоже есть некоторый смысл, если есть подозрение, что там может быть раскрытие макроса.

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


SD>А коли к тому еще и else добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.

У тебя нет денег на мышку с колёсиком? Я вообще думал, что такие уже лет 20 вообще не делают. По-моему, как раз такие мышки без колёсика в наше время должны стоить космических денег


SD>Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга.

Как человек, читающий много кода — нет ничего хуже K&R стиля


SD>Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.

Это идиотизм другого рода — слишком тупой рефакторинг. Нормальный рефакторинг сделал бы из этой кучи параметров struct Context, которая передавалась бы единственным аргументом, и которую было бы легко дополнять, не меняя сигнатуры функций. У меня такое бывает, и после пары расширений списка параметров набора функций параметры сначала переезжают в контекст, а при дальнейшем рефакторинге это становится классом со своими методами. А старые функции, принимавшие структуру контекста, вырождаются в функции, вызывающие методы класса контекста.
Но этот даже такой тупой рефакторинг обычно производится не потому, что "функция слишком длинная", а потому, что понадобилось написать ещё одну функцию, которой нужна часть кода из это 60ти-строчной функции.

Здравствуйте, SkyDance, Вы писали:

SD>Зато я знаю. Дело в том, что сделать автоформаттер, который делает нормальный reflow, — довольно сложная задача, требуется очень хорошо подумать. К тому же асимптотическая сложность известного мне алгоритма reflow — O(N^3). Первые автоформаттеры обычно работали целиком над файлом, и при такой сложности на больших файлах тупили неимоверно. Соломоново решение — а нафиг надо, сделаем тупейший алгоритм, так что каждый аргумент на своей строчке. И плевать, что это делает код нечитаемым. Ведь задача поставлена — сделать автоформаттер, а не "сделать так, чтобы было удобно читать код".

А что мешает делать O(N^3) но в пределах одной функции? Какая разница что там между функциями?

TB>А что мешает делать O(N^3) но в пределах одной функции? Какая разница что там между функциями?

Когда писали первые автоформаттеры, не умели еще так. А сейчас уже поздно. Дело в том, что подобные "решения" перерешить уже нереально. Примерно как законы в США, по которым перед машиной должен идти человек с флажком. Только робот-автоформаттер этот закон таки выполняет, в отличие от человеков с флажками.

Здравствуйте, SkyDance, Вы писали:

S>>Вот пример кода другого разработчика который я недавно переформатировал. Какой из вариантов готов к дальнейшему расширению?

SD>Первоначальный вариант лучше: объем контекста одинаков, функции исполняются строго последовательно, читать одну функцию проще, чем скакать по нескольким.

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

SD>К тому же ни одна из выделенных функций сама по себе не имеет применения. То есть выделение функции просто ради выделения. Зачем?
Для дальнейшего расширения функциональности, которой у разных функций будет разное.

SD>Выделять надо там, где или становится доступным повторное использование, или можно уменьшить размер контекста (путем передачи, скажем, 3 параметров вместо 12). Лучше и то, и другое сразу. Но если в конечном итоге все равно нужно разбираться, то проще разобраться в одной, чем в 5 функциях.


https://www.rsdn.org/article/patterns/rtp4.xml

Long Method

Здравствуйте, Marty, Вы писали:

M>Открывающая скобка в той же строке, где и условие/цикл экономит только одну строку текста, но тратит кучу ментальных сил читающего этот говнокод.

Не тратит


M>Я так обычно не делаю, да, это лишнее, если и if и его последующие else if все обходятся одной строчкой. Я экономлю строку таким образом:

M>

if (cond==1)
M>    ++x;
M>// dobavitb pustuiy stroku dlia chitaemosti
M>else if (cond==10)
M>    x += 2;
M>// dobavitb pustuiy stroku dlia chitaemosti
M>else if (cond==11)
M>    x += 25;
M>// dobavitb pustuiy stroku dlia chitaemosti
M>else
M>    x = 100500;
M>

Так что ли?

M>Ещё момент такой — мне рассказывал знакомый, который скачет между языками, и много пишет как на плюсах, так и на питоне. Он говорил: "переключаясь с питона на плюсы я могу профакапить момент, что вложенность в плюсах не определяется отступом, поэтому любое вложенное выражение, даже однострочное, обрамляю на плюсах скоупом".

КАк можно профакапить отступ при наличии хоть какого-то автоформаттера?

M>У тебя нет денег на мышку с колёсиком? Я вообще думал, что такие уже лет 20 вообще не делают. По-моему, как раз такие мышки без колёсика в наше время должны стоить космических денег

Неоходимость скроллинга негативно влияет на читаемость

Здравствуйте, SkyDance, Вы писали:

Pzz>>Полагаю, эти 72 символа взялись не с потолка, а с практики книгопечатанья или написания писем и основаны на накопленном опыте, а не случайны.

SD>"Но он же не ветеринар!" (С) анекдот.

SD>Да, книжная строка, в которой 72 символа, и где-то 60-64 непустых в среднем, вполне комфортны. Однако агрессивные стадА любителей под одну гребенку всегда требуют, чтобы гребенка была их. А значит, для "{" и "}" требуется отдельная строчка, и написать if (a > 1) x++ следует не в одну, а в 3 строки (или 4, если, как нравится многим, перед if требуется оставить пустую строку):

SD>

SD>if (a > 1)
SD>{
SD>  x++;
SD>}
SD>

SD>А коли к тому еще и else добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.

С этим согласен. Я begin и ставлю в конце строки против общепринятых правил, else тоже проединяю к предыдущей строке.
В Строку должно ровно то , на что можно поставить точку останова.
Сооветвественно 2 оператора в одной строке не должно быть, кроме тривиальных случаев, не требующих отладки.

SD>Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга.

Есть разница между "читать" и "разрабатывать, поддерживать".
Мне вот комфортно читать чужие библиотеки с модулями по 10-30 тыс строк, где все в одном месте, как они их там поддерживают — мне плевать.
А иметь свои модули такой длины — исключено.

SD>Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.

Не идиотизм. Я в своем коде вряд ли найду метод длиннее экрана (40 строк), который бы не просился бы на разделение, и разделялся бы естественно.
Если там такая длина, значит какие-то наверняка разделяемые части, или несколько вложенных итераций по структурам, или куча обработки исключительных ситуаций.
Во всех случаях лучше разделять на разные методы.
Исключение — инициализация каких-нибудь массивов однотипными структурами, и то часто группируются по разделам.

Здравствуйте, Shmj, Вы писали:

S>Вот, по умолчанию в той же Idea — около 75 символов. По сути это газетная строка или близко к ней.

S>А ведь можно было сделать длинным? Ну хотя бы 150-200 символов. И читать код как книгу. Тем более мониторы то расширяются.

S>Не пробовали? Что лучше? Сколько символов ставите?

Подкинули ссылку: Хабр: 100 символов, или Как влияет длина строки на читаемость текста

Здравствуйте, Shmj, Вы писали:

S>Не пробовали? Что лучше? Сколько символов ставите?

Попытка всем навязать работать в 600 на 800 на мониторе 17" ?
И ради этого всех заставить запоминать почему глобальная переменная называется brt?

Все это снижает произаодительност и приводит к росту числа ошибок.