diff options
Diffstat (limited to '')
| -rw-r--r-- | content/posts/2025-04-05-tabs-or-spaces/index.md (renamed from content/posts/2025-04-05-tabs-or-spaces.md) | 56 |
1 files changed, 27 insertions, 29 deletions
diff --git a/content/posts/2025-04-05-tabs-or-spaces.md b/content/posts/2025-04-05-tabs-or-spaces/index.md index a44e052..8122e06 100644 --- a/content/posts/2025-04-05-tabs-or-spaces.md +++ b/content/posts/2025-04-05-tabs-or-spaces/index.md @@ -1,12 +1,12 @@ --- categories: -- Размышления -date: '2025-04-05T16:53:27+03:00' + - Размышления +date: "2025-04-05T16:53:27+03:00" description: null image: null location: Казань tags: -- размышления + - размышления title: Табы или пробелы? --- @@ -31,22 +31,22 @@ title: Табы или пробелы? выбора то нет. Конечно же, только табы! Отступ пробелами просто не имеет права на жизнь, и вот почему: -* Во-первых, это просто какой-то костыль, использовать пробел не по назначению. +- Во-первых, это просто какой-то костыль, использовать пробел не по назначению. Наверное, не очень очевидно, но назначение пробела — это именно разделение слов. Невероятно! А наначение таба — как раз таки форматирование отступа. Давайте использовать инструменты по назначению! -* Во-вторых, и самое главное, как по мне, это гибкость табуляции. Я, как +- Во-вторых, и самое главное, как по мне, это гибкость табуляции. Я, как читающий код, волен сам выбирать размер отступа. Например, если у меня узкий - экран (смартфон, например) — я выберу отступ в 2 *визуальных* пробела. + экран (смартфон, например) — я выберу отступ в 2 _визуальных_ пробела. Наоборот, если бы у меня было слабое зрение — я бы выбрал отступ в бо́льшее - число *визуальных* пробелов. -* В-третьих, исходя из предыдущего пункта, я считаю, что использование именно + число _визуальных_ пробелов. +- В-третьих, исходя из предыдущего пункта, я считаю, что использование именно пробелов — это диктование автором исходника мне своей воли в виде своих предпочтений (например, только 4 пробела, и никак иначе!). А какого чёрта? Это буквально насилие! Зачем? Я считаю, это не допустимо. Пусть у каждого будет - возможность выбирать себе настройки отображения на *своей* машине под *свои* + возможность выбирать себе настройки отображения на _своей_ машине под _свои_ вкусы, а не вкусы автора! -* В-четвёртых, самое малозначительное — это то, что таб это 1 байт, а пробелов +- В-четвёртых, самое малозначительное — это то, что таб это 1 байт, а пробелов обычно больше чем 1 байт (от 2 до 8). Я считаю этот аргумент малозначительным, т.к. уж что что, а места на носителях информации нынче в достатке. Но тем не менее, это один из аргументов! @@ -56,7 +56,7 @@ title: Табы или пробелы? почему, вроде как, умные люди которые эти стандарты придумывали так сделали. Возможно, привычка. Но является ли привычка каких-то людей аргументом? Наверное, нет. И самое грустное, что эти стандарты уже не поменять, ибо с их -использованием *уже* написаны мегатонны кодов. +использованием _уже_ написаны мегатонны кодов. Единственное, меня радует, что хотя бы в стандарте форматирования моего любимого языка Go этой откровенной чуши нет. В Go отступы приняты табами и только ими. @@ -103,7 +103,7 @@ soft-wraps. Если коротко, при hard-wraps в текст в точк > 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. +> content correctly. Сначала, я подумал, да это же нифига не удобно, что используются длинные строки, а не склеиваются разделённые одним переносом как в Markdown! Более того, это моё @@ -122,7 +122,7 @@ hard-wraps и форматировал что код, что markdown для б преформатированный текст, при парсинге которого надо помнить состояние. Но и это очень просто, достаточно держать единственный флаг который говорит, мы сейчас в нормальном состоянии или в состоянии преформатированного текста. И переключать -этот флаг когда очередная строка начинается с *```*. Вообще, Gemtext кажется +этот флаг когда очередная строка начинается с _```_. Вообще, Gemtext кажется наиболее правильным и приятным для меня языком разметки. Наверное, я на него перейду. Но потом, сейчас нет времени. @@ -133,10 +133,10 @@ hard-wraps и форматировал что код, что markdown для б И вот аргументы: -* Во-первых, все редакторы кода поддерживают soft-wrap и каждый волен выставить +- Во-первых, все редакторы кода поддерживают soft-wrap и каждый волен выставить для своего личного редактора удобную ему длину строки, а не подчиняться привычкам автора кода. -* Во-вторых, за длину в 80 символов топят в основном старпёры что-то там +- Во-вторых, за длину в 80 символов топят в основном старпёры что-то там говорящие про терминалы шириной в 80 символов. Только и этот аргумент не понятен. Когда вы в последнее время видели терминал в 80 символов? Не эмулятор терминала, а именно сам терминал? Ну даже, хорошо, пусть будет этот терминал в @@ -145,10 +145,10 @@ hard-wraps и форматировал что код, что markdown для б современное в 120) выглядит как высосанное из пальца, потому что под ним нет реальной основы кроме каких-то там исторических причин на доисторическом железе. -* В-третьих, см. пункт про насилие автора кода над читателем кода. Например, +- В-третьих, см. пункт про насилие автора кода над читателем кода. Например, опять таки, узкий монитор например. И на нём не soft-wrapped текст может вызывать горизонтальную прокрутку. И это убого. -* В-четвёртых, да, это усложняет парсинг. Это слабый аргумент, я знаю. Как +- В-четвёртых, да, это усложняет парсинг. Это слабый аргумент, я знаю. Как пример, правильный парсер Markdown (не буду тут бомбить про количество разных стандартов Markdown) пишется не то чтобы очень просто. В это же время, написать парсер Gemtext который полностью покроет спецификацию — дело максимум @@ -168,7 +168,7 @@ hard-wraps и форматировал что код, что markdown для б > Мне есть что сказать про ширину таба и 80 символов. > Аргумент про разную ширину таба работает слабо: многие стили предполагают его -> фиксированную длину. Если ставить другой, то форматирование ломается. +> фиксированную длину. Если ставить другой, то форматирование ломается. > Пример: ядро Linux, где ширина таба 8, и аргументы функций "плывут" при другой > ширине. @@ -177,7 +177,7 @@ hard-wraps и форматировал что код, что markdown для б ли разница для читающего код, как именно он его видит: ``` -// tabsize=2 +/ tabsize=2 func someFunc( one, two, @@ -194,7 +194,7 @@ hard-wraps и форматировал что код, что markdown для б или так ``` -// tabsize=4 +/ tabsize=4 func someFunc( one, two, @@ -211,7 +211,7 @@ hard-wraps и форматировал что код, что markdown для б или даже так ``` -// tabsize=8 +/ tabsize=8 func someFunc( one, two, @@ -228,10 +228,9 @@ hard-wraps и форматировал что код, что markdown для б Кажется, что для 8 пробелов на таб всё сильно уезжает, но раз человек себе так настроил — то как будто его право и наверное были основания? - > Про 80 символов. Дело вообще не в размере терминала или ширине перфокарты. > Некоторые программисты разделяют редактор на две вкладки, чтобы смотреть два -> файла. +> файла. И тогда soft-wrap как раз и вместит весь код в каждую из половинок без горизонтальной прокрутки, о чём я и говорю. @@ -239,7 +238,7 @@ hard-wraps и форматировал что код, что markdown для б > Некоторые используют большой шрифт. С шириной в 120 символов мы лишаем из > возможности удобно читать код. К тому же, я считаю этот аргумент важным, 120 > символов - это способ замаскировать плохой код. Чувак сделал 5 уровней -> вложенности в коде? Отлично! Главное чтобы в 120 символов влезло. +> вложенности в коде? Отлично! Главное чтобы в 120 символов влезло. Всё так! Возможно, я не очень подробно расписал, но основная моя мысль в том, что такое жесткое ограничение мне кажется просто надуманным и взятым с потолка. @@ -328,7 +327,6 @@ P.S.: Из забавного => https://tonsky.me/blog/disenchantment/ru/ [2] - ## Update 06.04.25 - 2 Со вчерашнего дня я решил дополнить немного ещё. @@ -344,7 +342,7 @@ P.S.: Из забавного → → Const3 = 3 ``` -для меня вполне нормально кажется. Даже более того, табы *внутри* строки кажутся +для меня вполне нормально кажется. Даже более того, табы _внутри_ строки кажутся плохим решением. Я говорю только про отступы в начале строки. Во-вторых, насчёт длинных строк. Я расписал немного сумбурно и в одну кашу @@ -352,17 +350,17 @@ P.S.: Из забавного но я всё равно считаю жесткое ограничение необоснованным ни там ни там. Но по разным причинам: -* Для обычного текста ограничение в N символов выглядит таким же не обоснованым, +- Для обычного текста ограничение в N символов выглядит таким же не обоснованым, как, например, требование автора «Читайте мои тексты только шрифтом Arial 12pt». Глупость? Глупость. -* Так же встречал, что люди используют это ограничение при написании электронных +- Так же встречал, что люди используют это ограничение при написании электронных писем. Это выглядит как минимум странно. Письмо пишется для кого? Для получателя, т.е. читателя. Почему отправитель за читателя решает то, как у него будет отображаться письмо? Я часто читаю почту со смартфона с узким экраном, но средним шрифтом (чтобы меньше напрягать глаза). И горизонтальная прокрутка выглядит не очень. Горизонтальная прокрутка вообще почти всегда выглядит не очень и её стоит избегать всеми силами. -* Для кода же история другая. Я не настолько поехал чтобы требовать всё писать в +- Для кода же история другая. Я не настолько поехал чтобы требовать всё писать в одну строку. Если у функции в сигнатуре много (больше одного - двух) аргументов — то это отличная идея написать их в столбик, а не в длинную линию, которая ещё неизвестно как перенесётся. Я против именно переноса только из-за |