1 files changed, 67 insertions, 0 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
new file mode 100644
index 0000000..f0c4b2b
--- /dev/null
+++ b/content/posts/2025-04-05-tabs-or-spaces/index.md
@@ -0,0 +1,67 @@
+---
+title: Табы или пробелы?
+description:
+date: 2025-04-05T16:53:27+03:00
+categories:
+    - Размышления
+tags:
+    - размышления
+location: Казань
+image:
+---
+
+Так получилось, что с Нового Года я ничего в блог не писал. Тому причина в личной загруженности, и в не менее личной лени. Так же я делал некоторые эксперименты над самим блогом, потому что моё внутреннее чувство прекрасного не даёт мне просто остановиться и не трогать то, что работает.
+
+Но всё же, я чувствую внутреннюю потребность написать небольшую заметку с размышлениями, которые недавно приходили ко мне в голову.
+
+А связаны они с тем, что есть определённые догмы в индустрии, которые непонятно (ну или понятно) почему появились, и которым слепо следуют, хотя, как будто они уже не имеют смысла.
+
+<!--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 который полностью покроет спецификацию — дело максимум часа-двух для любого, кто программирует больше, хотя бы, нескольких месяцев!
+
+В общем, как и в случае с табо-пробелами я не вижу ни одной достойной причины делать жесткие переносы строк по какой-то длине!
+
+Возможно, я что-то упустил — тоже можно по этому поводу поспорить со мной в электропочте. Возможно, я даже поменяю мнение, но наврядли.
+\ No newline at end of file