diff options
Diffstat (limited to 'content/posts/2025-04-05-tabs-or-spaces.md')
| -rw-r--r-- | content/posts/2025-04-05-tabs-or-spaces.md | 400 |
1 files changed, 0 insertions, 400 deletions
diff --git a/content/posts/2025-04-05-tabs-or-spaces.md b/content/posts/2025-04-05-tabs-or-spaces.md deleted file mode 100644 index a44e052..0000000 --- a/content/posts/2025-04-05-tabs-or-spaces.md +++ /dev/null @@ -1,400 +0,0 @@ ---- -categories: -- Размышления -date: '2025-04-05T16:53:27+03:00' -description: null -image: null -location: Казань -tags: -- размышления -title: Табы или пробелы? ---- - -Так получилось, что с Нового Года я ничего в блог не писал. Тому причина в -личной загруженности, и в не менее личной лени. Так же я делал некоторые -эксперименты над самим блогом, потому что моё внутреннее чувство прекрасного не -даёт мне просто остановиться и не трогать то, что работает. - -Но всё же, я чувствую внутреннюю потребность написать небольшую заметку с -размышлениями, которые недавно приходили ко мне в голову. - -А связаны они с тем, что есть определённые догмы в индустрии, которые непонятно -(ну или понятно) почему появились, и которым слепо следуют, хотя, как будто они -уже не имеют смысла. - -<!--more--> - -## Вечный спор - -Для затравки, «вечный спор» табы или пробелы использовать в коде для отсутпов. -Лично для меня здесь не то что выбор очевиден, для меня очевидно, что и самого -выбора то нет. Конечно же, только табы! Отступ пробелами просто не имеет права -на жизнь, и вот почему: - -* Во-первых, это просто какой-то костыль, использовать пробел не по назначению. - Наверное, не очень очевидно, но назначение пробела — это именно разделение - слов. Невероятно! А наначение таба — как раз таки форматирование отступа. - Давайте использовать инструменты по назначению! -* Во-вторых, и самое главное, как по мне, это гибкость табуляции. Я, как - читающий код, волен сам выбирать размер отступа. Например, если у меня узкий - экран (смартфон, например) — я выберу отступ в 2 *визуальных* пробела. - Наоборот, если бы у меня было слабое зрение — я бы выбрал отступ в бо́льшее - число *визуальных* пробелов. -* В-третьих, исходя из предыдущего пункта, я считаю, что использование именно - пробелов — это диктование автором исходника мне своей воли в виде своих - предпочтений (например, только 4 пробела, и никак иначе!). А какого чёрта? Это - буквально насилие! Зачем? Я считаю, это не допустимо. Пусть у каждого будет - возможность выбирать себе настройки отображения на *своей* машине под *свои* - вкусы, а не вкусы автора! -* В-четвёртых, самое малозначительное — это то, что таб это 1 байт, а пробелов - обычно больше чем 1 байт (от 2 до 8). Я считаю этот аргумент малозначительным, - т.к. уж что что, а места на носителях информации нынче в достатке. Но тем не - менее, это один из аргументов! - -А что по аргументам за пробелы? Да нет их. Ну окей, предположим, что есть. Во -многих кодстайлах (PEP-8, PSR итп) закреплены именно пробелы. Я не понимаю, -почему, вроде как, умные люди которые эти стандарты придумывали так сделали. -Возможно, привычка. Но является ли привычка каких-то людей аргументом? Наверное, -нет. И самое грустное, что эти стандарты уже не поменять, ибо с их -использованием *уже* написаны мегатонны кодов. - -Единственное, меня радует, что хотя бы в стандарте форматирования моего любимого -языка Go этой откровенной чуши нет. В Go отступы приняты табами и только ими. - -Сразу скажу, я говорил только про отступы в начале строки, но не про отступы -внутри строки, например, чтобы выстраивать значения подряд идущих констант в -одну ровную колонку. Там, вроде как, пробелы вполне оправданы. Но это не точно. -Я пока не решил для себя. - -Думаю, здесь насчёт табов и пробелов можно завершить. Если есть что накинуть — -пишите письма, e-mail внизу страницы. - -## Вечный консенсус - -Про табы и пробелы была скорее затравочка. Там, как мне кажется, всё очевидно. -Но есть менее очевидная, но как мне кажется очень родственная тема. Эта тема -вызывает сильно меньше споров, т.к. вроде как в ней уже есть консенсус. Но этот -консенсус ошибочен! - -А говорю я про форматирование длины строк! А именно, т.н. hard-wraps и -soft-wraps. Если коротко, при hard-wraps в текст в точках переноса (например, на -80 или 120 колонке) вставляются символ переноса строк (`\n`), при мягком -переносе текст остается на одной строке, но выглядит так, как будто он разделен -на несколько строк. - -А начну я с небольшой предыстории, как я к этому пришёл. Как я уже писал в -начале, у меня есть постоянное шило в седалище, которое не даёт мне просто -остановиться и использовать то, что работает, как минимум, в контексте этого -блога. И из последнего куда я смотрел — протокол Gemini[1]. Разбирая его, меня -сначала немного удивила его особенность, а именно: - -=> https://geminiprotocol.net/ [1] - -> Text in Gemtext documents is written using "long lines", i.e. you (or your -> editor) shouldn't be inserting newline characters every 80 characters or so. -> Instead, leave it up to the receiving Gemini client to wrap your lines to fit -> the device's screen size and the user's preference. This way Gemtext content -> looks good and is easy to read on desktop monitors, laptop screens, tablets -> and smartphones. - -> Note that while Gemini clients will break up lines of text which are longer -> than the user's screen, they will not join up lines which are shorter than the -> user's screen, like would happen in Markdown, HTML or LaTeX. This means that, -> e.g. "dot point" lists or poems with deliberately short lines will be -> displayed correctly without the author having to do any extra work or the -> client having to be any smarter in order to recognise and handle that kind of -> content correctly. - -Сначала, я подумал, да это же нифига не удобно, что используются длинные строки, -а не склеиваются разделённые одним переносом как в Markdown! Более того, это моё -возмущение подогревалось тем, что я всё это время был сторонником как раз -hard-wraps и форматировал что код, что markdown для блога по 80 или 120 колонке. -Потому что так всегда и везде было принято. Но потом вчитавшись, я понял, что -как раз таки «склеивание» Markdown это максимально неправильное поведение! Оно -порождает такие минусы, как более сложный парсинг, который должен обрабатывать -по разному один и два переноса строк, неочевидность, когда пишешь текст в -редакторе, а отображается он совсем по другому, потенциальные ошибки, когда -абзацы внезапно склеиваются, и т.п. - -При этом, парсинг Gemtext поразительно простой. В общем случае, достаточно -парсить по строке, и не думать о предыдущем состоянии (относится текущая строка -к предыдущему параграфу или таки нет). Единственное исключение — -преформатированный текст, при парсинге которого надо помнить состояние. Но и это -очень просто, достаточно держать единственный флаг который говорит, мы сейчас в -нормальном состоянии или в состоянии преформатированного текста. И переключать -этот флаг когда очередная строка начинается с *```*. Вообще, Gemtext кажется -наиболее правильным и приятным для меня языком разметки. Наверное, я на него -перейду. Но потом, сейчас нет времени. - -К чему я тут углубился в описание формата Gemtext? А вот к чему: только после -прочтения спеки этого формата до меня сошло озарение, что использование длинных, -а не обрезанных по 80 или 120 или ещё какую колонку более правильное не только -для формата разметки, но и для обычного кода! - -И вот аргументы: - -* Во-первых, все редакторы кода поддерживают soft-wrap и каждый волен выставить - для своего личного редактора удобную ему длину строки, а не подчиняться - привычкам автора кода. -* Во-вторых, за длину в 80 символов топят в основном старпёры что-то там - говорящие про терминалы шириной в 80 символов. Только и этот аргумент не - понятен. Когда вы в последнее время видели терминал в 80 символов? Не эмулятор - терминала, а именно сам терминал? Ну даже, хорошо, пусть будет этот терминал в - 80 символов. Но он что, не умеет переносить? Подозреваю, что может. И в чём - тогда проблема? Непонятно. Короче, требование в 80 символов (ну или более - современное в 120) выглядит как высосанное из пальца, потому что под ним нет - реальной основы кроме каких-то там исторических причин на доисторическом - железе. -* В-третьих, см. пункт про насилие автора кода над читателем кода. Например, - опять таки, узкий монитор например. И на нём не soft-wrapped текст может - вызывать горизонтальную прокрутку. И это убого. -* В-четвёртых, да, это усложняет парсинг. Это слабый аргумент, я знаю. Как - пример, правильный парсер Markdown (не буду тут бомбить про количество разных - стандартов Markdown) пишется не то чтобы очень просто. В это же время, - написать парсер Gemtext который полностью покроет спецификацию — дело максимум - часа-двух для любого, кто программирует больше, хотя бы, нескольких месяцев! - -В общем, как и в случае с табо-пробелами я не вижу ни одной достойной причины -делать жесткие переносы строк по какой-то длине! - -Возможно, я что-то упустил — тоже можно по этому поводу поспорить со мной в -электропочте. Возможно, я даже поменяю мнение, но наврядли. - -## 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 -``` - -Вроде как, покрывает основное. |