Сообщение Re[4]: Ширина кода - газетная vs книжная от 17.01.2025 8:47
Изменено 17.01.2025 8:53 swame
Re[4]: Ширина кода - газетная vs книжная
Здравствуйте, SkyDance, Вы писали:
Pzz>>Полагаю, эти 72 символа взялись не с потолка, а с практики книгопечатанья или написания писем и основаны на накопленном опыте, а не случайны.
SD>"Но он же не ветеринар!" (С) анекдот.
SD>Да, книжная строка, в которой 72 символа, и где-то 60-64 непустых в среднем, вполне комфортны. Однако агрессивные стадА любителей под одну гребенку всегда требуют, чтобы гребенка была их. А значит, для "{" и "}" требуется отдельная строчка, и написать if (a > 1) x++ следует не в одну, а в 3 строки (или 4, если, как нравится многим, перед if требуется оставить пустую строку):
SD>
SD>А коли к тому еще и else добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.
SD>Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга.
Есть разница между "читать" и "разрабатывать, поддерживать".
Мне вот комфортно читать чужие библиотеки с модулями по 10-30 тыс строк, где все в одном месте, как они их там поддерживают — мне плевать.
А иметь свои модули такой длины — исключено.
SD>Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.
Не идиотизм. Я в своем коде вряд ли найду метод длиннее экрана (40 строк), который бы не просился бы на разделение, и разделялся бы естественно.
Если там такая длина, значит какие-то наверняка разделяемые части, или несколько вложенных итераций по структурам, или куча обработки исключительных ситуаций.
Во всех случаях лучше разделять на разные методы.
Исключение — инициализация каких-нибудь массивов однотипными структурами, и то часто группируются по разделам.
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 добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.
SD>Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга.
Есть разница между "читать" и "разрабатывать, поддерживать".
Мне вот комфортно читать чужие библиотеки с модулями по 10-30 тыс строк, где все в одном месте, как они их там поддерживают — мне плевать.
А иметь свои модули такой длины — исключено.
SD>Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.
Не идиотизм. Я в своем коде вряд ли найду метод длиннее экрана (40 строк), который бы не просился бы на разделение, и разделялся бы естественно.
Если там такая длина, значит какие-то наверняка разделяемые части, или несколько вложенных итераций по структурам, или куча обработки исключительных ситуаций.
Во всех случаях лучше разделять на разные методы.
Исключение — инициализация каких-нибудь массивов однотипными структурами, и то часто группируются по разделам.
Re[4]: Ширина кода - газетная vs книжная
Здравствуйте, SkyDance, Вы писали:
Pzz>>Полагаю, эти 72 символа взялись не с потолка, а с практики книгопечатанья или написания писем и основаны на накопленном опыте, а не случайны.
SD>"Но он же не ветеринар!" (С) анекдот.
SD>Да, книжная строка, в которой 72 символа, и где-то 60-64 непустых в среднем, вполне комфортны. Однако агрессивные стадА любителей под одну гребенку всегда требуют, чтобы гребенка была их. А значит, для "{" и "}" требуется отдельная строчка, и написать if (a > 1) x++ следует не в одну, а в 3 строки (или 4, если, как нравится многим, перед if требуется оставить пустую строку):
SD>
SD>А коли к тому еще и else добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.
С этим согласен. Я begin и ставлю в конце строки против общепринятых правил, else тоже проединяю к предыдущей строке.
В Строку должно ровно то , на что можно поставить точку останова.
Сооветвественно 2 оператора в одной строке не должно быть, кроме тривиальных случаев, не требующих отладки.
SD>Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга.
Есть разница между "читать" и "разрабатывать, поддерживать".
Мне вот комфортно читать чужие библиотеки с модулями по 10-30 тыс строк, где все в одном месте, как они их там поддерживают — мне плевать.
А иметь свои модули такой длины — исключено.
SD>Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.
Не идиотизм. Я в своем коде вряд ли найду метод длиннее экрана (40 строк), который бы не просился бы на разделение, и разделялся бы естественно.
Если там такая длина, значит какие-то наверняка разделяемые части, или несколько вложенных итераций по структурам, или куча обработки исключительных ситуаций.
Во всех случаях лучше разделять на разные методы.
Исключение — инициализация каких-нибудь массивов однотипными структурами, и то часто группируются по разделам.
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 строк), который бы не просился бы на разделение, и разделялся бы естественно.
Если там такая длина, значит какие-то наверняка разделяемые части, или несколько вложенных итераций по структурам, или куча обработки исключительных ситуаций.
Во всех случаях лучше разделять на разные методы.
Исключение — инициализация каких-нибудь массивов однотипными структурами, и то часто группируются по разделам.