diff options
Diffstat (limited to 'content/posts/2025-04-05-tabs-or-spaces/index.md')
| -rw-r--r-- | content/posts/2025-04-05-tabs-or-spaces/index.md | 178 |
1 files changed, 177 insertions, 1 deletions
diff --git a/content/posts/2025-04-05-tabs-or-spaces/index.md b/content/posts/2025-04-05-tabs-or-spaces/index.md index f0c4b2b..2edea61 100644 --- a/content/posts/2025-04-05-tabs-or-spaces/index.md +++ b/content/posts/2025-04-05-tabs-or-spaces/index.md @@ -64,4 +64,180 @@ image: В общем, как и в случае с табо-пробелами я не вижу ни одной достойной причины делать жесткие переносы строк по какой-то длине! -Возможно, я что-то упустил — тоже можно по этому поводу поспорить со мной в электропочте. Возможно, я даже поменяю мнение, но наврядли.
\ No newline at end of file +Возможно, я что-то упустил — тоже можно по этому поводу поспорить со мной в электропочте. Возможно, я даже поменяю мнение, но наврядли. + +## Update 06.04.25 + +Как я и просил, один хороший человек, Владислав (https://t.me/c/1331521959/2285), написал ответ. Прокомментирую его здесь: + +> Мне есть что сказать про ширину таба и 80 символов. + +> Аргумент про разную ширину таба работает слабо: многие стили предполагают его фиксированную длину. Если ставить другой, то форматирование ломается. + +> Пример: ядро Linux, где ширина таба 8, и аргументы функций "плывут" при другой ширине. + +Я не единожды видел этот аргумент, но он как раз и кажется мне слабым. Большая ли разница для читающего код, как именно он его видит: + +``` +// tabsize=2 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +или так + +``` +// tabsize=4 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +или даже так + +``` +// tabsize=8 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +Кажется, что для 8 пробелов на таб всё сильно уезжает, но раз человек себе так настроил — то как будто его право и наверное были основания? + + +> Про 80 символов. Дело вообще не в размере терминала или ширине перфокарты. Некоторые программисты разделяют редактор на две вкладки, чтобы смотреть два файла. + +И тогда soft-wrap как раз и вместит весь код в каждую из половинок без горизонтальной прокрутки, о чём я и говорю. + +> Некоторые используют большой шрифт. С шириной в 120 символов мы лишаем из возможности удобно читать код. К тому же, я считаю этот аргумент важным, 120 символов - это способ замаскировать плохой код. Чувак сделал 5 уровней вложенности в коде? Отлично! Главное чтобы в 120 символов влезло. + +Всё так! Возможно, я не очень подробно расписал, но основная моя мысль в том, что такое жесткое ограничение мне кажется просто надуманным и взятым с потолка. А если я после функции хочу написать небольшой коммент и он ну никак не влезает на пяток символов? Новую строку ради этого делать? Ну как-то бредово. А для указанного случая гораздо лучше бы звучало ограничение в стандарте типа «не используйте больше 3 уровней вложенности в коде». Это хотя бы имело вполне себе обоснование, то что скорее всего такой код просто архитектурно неверен и его стоит пересмотреть. + +> Конечно, можно сказать что есть длинные константы или имена функций, но этот спор становится менее однозначным. Как по мне вполне хороший консенсус - это 100 символов в строке + +Здесь не согласен. Здесь опять «магическая константа» с потолка. + +> В целом, эти срачи мне кажутся достаточно поверхностными. Они в своем корне несут вопрос "как повысить читаемость кода?", но акцентируются на мелочах. + +Согласен. Мелочи. Но почему и бы про мелочи не поговорить :) Из них по отдельности всё и строится (избитая фраза, да). В больших стандартах обычно говорится просто декларативно «только пробелы, отступ 4 пробела, длина строк 120» и всё. А зачем и почему — опускается, как будто всем всё и так понятно. Мне вот не очень. Чувствую себя ребёнком спрашивающим «Почему небо синее?». Потому что мне кажется, что под этим требованием нет объективного требования кроме «так принято». А «так принято» я часто и принимаю как валидный аргумент, например, когда прихожу в какой-то проект, но в сути своей аргументом не является. + +> Хотелось бы иметь какие-то объективные метрики, какая-то работа в этом направлении была проделана, но, как я понял, это, во-первых, недостаточно точные метрики, а во-вторых, недостаточно развитая история. https://seeinglogic.com/posts/visual-readability-patterns/ + +Интересная статья, спасибо, с удовольствием прочитал. В целом, по выводам (https://seeinglogic.com/posts/visual-readability-patterns/#8-patterns-for-improving-code-readability) согласен. Метрика по Хольстеду (или как это перевести?) выглядит интересно, тем что она чётко считается (хотя когда я руками считал, что-то у меня не сошлось с примером :) ). + +Из объективных метрик, тут вскользь ещё упоминалась цикломатическая сложность, которая вполне себе имеет право на жизнь. + +А так же, только что пришло в голову что можно читабельность кода оценивать как вторую (?) производную от отступов по непустым строкам. При этом, чем эта производная ближе к нулю — тем лучше. + +То есть, грубо говоря вот такой «код»: + +``` +_____ + ________ + _____ + _______ + ___ + ___ + _____ + __ + ____ +___ +``` + +Лучше чем, такой: + +``` +_____ + ________ + _____ + _______ + ___ + ___ + _____ + __ + ____ + ___ +``` + +Это стоит ещё подумать, это буквально пришло в голову только что, пока читал статью. + +P.S.: Из забавного + +> As others have written, computers are fast and premature optimization is a bad thing. + +Сначала они пишут «computers are fast» а потом происходит такое: [2] + +=> https://tonsky.me/blog/disenchantment/ru/ [2] + + +## Update 06.04.25 - 2 + +Со вчерашнего дня я решил дополнить немного ещё. + +Во-первых, хочу немного снизить градус холиворности и радикальности. Ещё раз упомяну что не вижу проблем для выравнивания пробелами текста внутри строки. То есть например, вот так: + +``` +→ → ConstWithLongName = 0 +→ → Const1 = 1 +→ → Const2 = 2 +→ → Const3 = 3 +``` + +для меня вполне нормально кажется. Даже более того, табы *внутри* строки кажутся плохим решением. Я говорю только про отступы в начале строки. + +Во-вторых, насчёт длинных строк. Я расписал немного сумбурно и в одну кашу смешал как код, так и просто текст. Не стоило так. Хоть это и разные сущности, но я всё равно считаю жесткое ограничение необоснованным ни там ни там. Но по разным причинам: + +* Для обычного текста ограничение в N символов выглядит таким же не обоснованым, как, например, требование автора «Читайте мои тексты только шрифтом Arial 12pt». Глупость? Глупость. +* Так же встречал, что люди используют это ограничение при написании электронных писем. Это выглядит как минимум странно. Письмо пишется для кого? Для получателя, т.е. читателя. Почему отправитель за читателя решает то, как у него будет отображаться письмо? Я часто читаю почту со смартфона с узким экраном, но средним шрифтом (чтобы меньше напрягать глаза). И горизонтальная прокрутка выглядит не очень. Горизонтальная прокрутка вообще почти всегда выглядит не очень и её стоит избегать всеми силами. +* Для кода же история другая. Я не настолько поехал чтобы требовать всё писать в одну строку. Если у функции в сигнатуре много (больше одного - двух) аргументов — то это отличная идея написать их в столбик, а не в длинную линию, которая ещё неизвестно как перенесётся. Я против именно переноса только из-за магической константы колиечества символов. + +Да и вообще я ни от кого ничего не требовал. Я предлагаю только задуматься, а обоснованны ли «общепринятые» вещи? Может, уже прошло какое-то время и ситуация поменялась и удобнее и эффективнее выбрать что-то другое? + +И как будто стоит абстрактному «читателю», к которому я отсылал, в этом посте, решать этот вопрос техническими средствами, типа editorconfig + pre-commit хуки на форматирование в принятый в команде формат? Возможно да. Иначе получится, что борясь за личную свободу — нарушаешь чужую свободу <del>писать говнокод</del>. + +А .editorconfig я себе такой в home положил: + +```.editorconfig +[*] +indent_style = tab +tab_width = 4 +end_of_line = lf +charset = utf-8 +trim_trailing_whitespace = true +insert_final_newline = true +soft_wrap = true + +[*.{yml,yaml}] +indent_style = space +indent_size = 2 + +[*.json] +indent_size = 2 +``` + +Вроде как, покрывает основное. |