".
Я хотел было ответить к комментариях, но в силу объема и желания независимости от исходного топика решил создать новый топик.
Итак, под катом - почему табы лучше пробелов, самые значительные заблуждения касательно табов и как ими правильно пользоваться.
Начнём с того, что большинство людей (по крайней мере на Хабре) предпочитают табы.
На самом деле странно то, что многие до сих пор не отличают indentation и alignment. Ну, вот это - indentation:
for (int i = 0; i < 10; i++) { if (a[i] == 0) do_something(i); }А вот это - alignment:
int some_variable = 0; int v1 = 0;Первое можно делать и табами, и пробелами, но когда делаешь табами - каждый может подстроить ширину indent"а на свой вкус и ничего никуда не едет. А второе - строго пробелами.
В IDE есть опция Smart Tabs для этого:
Если правильно использовать табы (а именно - только для indentation) - можно без проблем менять размер табов не нарушая стиль программирования.
2 пробела на таб:
5 пробелов на таб:
9 пробелов на таб:
Процитирую пару мыслей из предыдущего топика:
Тяжело работать с проектами, где используются библиотеки, содержащие в тесте табуляции. Предположим, в одной библиотеке табуляция равна 3 символам, в другой 4 символам. А вы в проекте используете 2 символа. В результате какая-то часть кода у вас будет отображаться в редакторе со сбитым форматированием.
Легко пустить козла в огород. Скажем у вас табуляция равна 4 пробелам. Кто-то что-то чуть-чуть поправил, используя другой размер табуляции или явно вставив пробелы. У него все смотрелось нормально, а у вас строчка кода куда-то уедет.
Надо постоянно настраивать различные редакторы под нужный вам размер табуляции. Даже если вам нужно просто посмотреть код не правя. Иначе все разъезжается. Особенно это не удобно, когда приходится что-то делать со своим кодом на сторонней машине.
Лишние сложности тем, кто работает одновременно с проектами, где по стандартам кодирования требуются разные отступы. Если стандарты требуют использование табуляции, то это ещё тот вечно ноющий зуб. В случае пробелов опять-таки все намного проще.
А еще дополнительно у пробелов есть такие недостатки, как невозможность быстрого перемещения стрелочками клавиатуры (щёлкает каждый пробел, а не через блок), возможность допустить ошибку (поставить в одном месте 3 пробела вместо 4, чем порушить дальнейшую структуру), увеличение размера файла и куча всего ещё.
Для пытливых разработчиков до сих пор остается актуальным вопрос использования табуляции и пробелов для форматирования кода. Могут ли они быть взаимозаменяемы: например, 2 пробела на табуляцию или 4? Но единого стандарта нет, поэтому иногда между разработчиками возникает непонимание. Кроме того, различные IDE и их компиляторы обрабатывают табуляцию также по-своему.
Решением вопроса обычно становится соглашение о правилах форматирования в рамках проекта или языка программирования в целом.
Команда разработчиков из Google исследовала проекты в репозитории Github. Они проанализировали код, написанный на 14 языках программирования. Целью исследования было выявить соотношение табуляций и пробелов - то есть, наиболее популярный способ форматирования текста для каждого из языков.
Напомним, что около двух месяцев назад весь открытый код Github стал доступен в форме таблиц BigQuery.
Однако для анализа были выбраны не все репозитории, а только верхние 400 тысяч репозиториев с наибольшим числом звёзд, которые они получили за период с января по май 2016 года.
Из этой таблицы были выделены файлы, содержащие код на 14 самых популярных языках программирования. Для этого в качестве параметров sql-запроса были указаны расширения соответствующих файлов – .java, .h, .js, .c, .php, .html, .cs, .json, .py, .cpp, .xml, .rb, .cc, .go.
SELECT a.id id, size, content, binary, copies, sample_repo_name , sample_path
FROM (SELECT id, FIRST(path) sample_path, FIRST(repo_name) sample_repo_name
FROM
WHERE REGEXP_EXTRACT(path, r"\.([^\.]*)$") IN ("java","h","js","c","php","html","cs","json","py","cpp","xml","rb","cc","go")
GROUP BY id) a
JOIN b
ON a.id = b.id
864.6s elapsed, 1.60 TB processed
В таблице записаны файлы без своих дубликатов. Ниже указано общее количество уникальных файлов и их суммарный размер. Дубликаты файлов не учитывались в ходе анализа.
После этого оставалось только сформировать и запустить на выполнение финальный запрос.
SELECT ext, tabs, spaces, countext, LOG((spaces+1)/(tabs+1)) lratio
FROM (SELECT REGEXP_EXTRACT(sample_path, r"\.([^\.]*)$") ext,
SUM(best="tab") tabs, SUM(best="space") spaces,
COUNT(*) countext
FROM (SELECT sample_path, sample_repo_name, IF(SUM(line=" ")>SUM(line="\t"), "space", "tab") WITHIN RECORD best,
COUNT(line) WITHIN RECORD c
FROM (SELECT LEFT(SPLIT(content, "\n"), 1) line, sample_path, sample_repo_name
FROM
HAVING REGEXP_MATCH(line, r"[ \t]"))
HAVING c>10 # at least 10 lines that start with space or tab)
GROUP BY ext)
ORDER BY countext DESC
LIMIT 100
16.0s elapsed, 133 GB processed
Чаще всего табуляция встречается в языке С, а пробелы - в Java.
Хотя для кого-то соотношение тех или иных управляющих символов не имеет значения, а споры на эту тему кажутся надуманными. Это не имеет значения и для некоторых IDE, которые сохраняют табуляцию как некоторое количество пробелов. Также существуют IDE, в которых это количество можно настраивать вручную.
Некоторое время назад эта проблема была обыграна в сериале «Кремниевая долина». Парень и девушка не сошлись в вопросе форматирования. В результате старый холивар не только привел к недопониманию в профессиональном плане, но и создал проблемы в их личных отношениях.
Бывают случаи, когда не хочется менять стили ради какого-то одного элемента, или необходимо вставить несколько пробелов в тексте из соображений эстетики или стилистики форматирования текста. И тут встает вопрос: «Как сделать пробел в HTML, чтобы текст красиво отображался, и при этом избежать избыточности кода?» Для этого рассмотрим виды пробелов и примеры их использования в HTML-коде.
В случаях, когда нужно не отрывать части текста друг от друга, поможет неразрывный пробел , код которого выглядит следующим образом:
Это так называемый, "non breaking space".
Примеры использования неразрывного пробела:
И т. д. т. к. Е. Велтистов 11 тыс. рублей
Код пробела HTML, который мы рассмотрели выше, является повсеместным. Но бывают случаи, когда обычный пробел оказывается слишком «большим». Тогда на смену ему приходит тонкий пробел . Это пробел, ширина которого составляет четверть кегля используемого шрифта. Обозначается тонкий пробел следующим образом:
и используется, по большей части, для разбиения разрядов чисел, например, "15 000 000 долларов" стоит записать так:
15 000 000 долларов
Примечание: Тонкий пробел может некорректно отображаться в старых версиях некоторых из браузеров, но во всех последних версиях работает на «ура».
Помимо наиболее актуальных видов, что мы рассмотрели выше, существуют и другие.
Примечание:
Если вам нужно поставить несколько пробелов подряд, обрамите текст тегом :
Конструктор сайтов «Нубекс»
Вариант создания табуляции (отступа) с помощью CSS можно решить с помощью следующего приёма:
Конструктор сайтов «Нубекс»
Один из признаков хорошего стиля программирования — последовательность — чем меньше сюрпризов, тем лучше. Последовательность позволяет легче читать программу, в первую очередь за счет сокращения отвлечений. Она также направляет глаза читателя, например, последовательность в расположении функции или подключении файлов упрощает их нахождение в будущем. Также она позволяет легче решать проблемы стиля, помогая читателю легче привыкнуть к нему.
Хороший стиль нужен для того, чтобы ваша программа была ясна и понятна, а также легко изменяемая. Если сомневаетесь, выберете наиболее понятную методику для проблемы. Помните, что все, что вы пишите, вам, вероятно, придется перечитывать. Облегчите себе будущее и вносите ясность сразу.
Пробелы могут уменьшить нагрузку на глаза читателя. Поскольку компилятор игнорирует пробелы, вы можете свободно размещать их в любом месте и форматировать код пробелами как хотите. Если вы делаете это с умом, это будет полезно.
Пробелы используются для форматирования отступов, пространства вокруг операторов, подписи функций и размещения аргументов функций. Конечно, это не все случая, где используются пробелы, но это должно дать вам представление о местах, где пробелы могут быть использованы для улучшения читабельности.
Если вы еще не делаете отступов в вашем коде, то скоро начнете. Это просто необходимо, потому что это поможет вам быстро находить нужные управляющие строки кода или найти ошибки в нем. Вам следует делать отступы в каждом блоке кода:
If (true) { // блок кода }
Есть множество способов для отступа в коде, и многие из них зависят от того, где вы разместите скобки. Некоторые люди предпочитают стиль, используемый выше. Некоторые люди предпочитают стиль, показанный ниже:
If (true) { // блок кода }
Есть и другие стили:
If (true) { // блок кода }
Какой стиль скобок вы выберете зависит от вас, хотя я рекомендую использовать одинаковый стиль скобок всем, кто работает над одним проектом. Во всяком случае, есть аргументы для каждого стиля. Хорошо использовать такой стиль скобок, который позволяет разместить максимальное количество кода на экране, однако последовательность так же важна.
Насколько вы собираетесь отступать — это вопрос личных предпочтений — в любом случае, как правило, лучше выбирать достаточно маленький размер отступа, чтобы код умещался на одном экране. Я считаю любой отступ шириной от 2 до 8, разумным и читаемым, хотя обнаружил, что более четырех пробелов для отступа могут привести к слишком длинным строкам.
В общем, лучшее решение для слишком длинных строк — снизить сложность кода или, по крайней мере, вытащить некоторые функции в отдельные функции. Это позволит уменьшить число уровней отступа и может сделать код более читаемым (если это делать правильно).
Существует своего рода спор по поводу использования табов или пробелов. Учтите, что это не то же самое, что спросить делаете ли вы отступы пробелами или табами. Большинство людей позволяют текстовому редактору решить это за них (или выбирает преобразовывать табы в пробелы).
Реальная проблема табов и пробелов заключается в том, что происходит, когда кто-то открывает ваш код. Вы можете установить табы для любого количества столбцов, а у человека, открывающего ваш код может быть другая ширина табуляции. Это может сыграть злую шутку даже с хорошо отформатированным кодом. Использование только пробелов исправляет эту проблему, потому что все будет отображаться одинаково.
Иногда достойный форматтер кода, который можно найти в текстовом редакторе, может помочь смягчить эту проблему путем переформатирования кода. Вы также можете изменить свои собственные настройки, чтобы отобразить код правильно (хоть это и не очень приятно).
Самое лучшее решение, если вы все-таки решите использовать табы, быть очень внимательным к тому, с чем вы их используете. Настоящая проблема, на самом деле, возникает, когда табы используются не только для отступа, но и как быстрый способ перемещения на четыре или восемь символов вправо. Например, давайте посмотрим на следующий код:
If (long_term_one && long_term_two) { // код }
Если второе условие было отформатировано с помощью таба с отступом в четыре пробела с последующим пробелом, то при открытии в другом редакторе с шириной табов в восемь пробелов, код будет выглядеть некрасиво:
If (long_term_one && long_term_two) { // код в теле оператора выбора }
Если для форматирования были использованы пробелы, код будет отображаться правильно:
If (long_term_one && long_term_two) { // код оператора if }
Сколько пробелов вы используете зависит только от вас. Но, стоит быть в курсе некоторых вопросов. Во-первых, чем больше пробелов помогает подчеркнуть логику вашей программы, тем лучше. Но вы не хотите, чтобы ваши пробелы дезориентировали вас. Это может не запутать вас в данный момент, но может сбить с толку вас в будущем, или кого-то еще, кто будет читать ваш код. Как же выглядит ошибочное форматирование?
If (true) ++i; ++j;
Отступ говорит нам, что два выражения сработают, при выполнении условного оператора, но это не то, что происходит на самом деле. Когда вы отслеживаете синтаксическую ошибку в сотнях или тысячах строк кода, вы, в конечном итоге, начинаете просто просматривать код, вместо тщательной проверки каждой строки. Чем проще вам будет просматривать код и выбрать важные детали, тем быстрее вы сможете найти закравшиеся незаметно ошибки. Как, например, в этом примере, к телу оператора if относится только первый оператор.
Среди программистов не утихают религиозные войны на тему форматирования кода. Один из острейших вопросов на эту тему — чем делать отступы и выравнивание в исходном коде программ — табуляцией, пробелами или одно — одним, а другое — другим? У каждого варианта, определённо, есть и свои плюсы, и свои минусы.
По моему наблюдению, среди матёрых программистов в большинстве случаев всё же побеждают сторонники пробелов, и решающим аргументом здесь служит визуальная одинаковость выровненных строк вне зависимости от настроек программы у каждого конкретного программиста. А о количестве пробелов в отступе они предпочитают договариваться внутри команды. Что им мешает так же договориться о величине таба — непонятно:)
Вероятно, актуальность использования пробелов возникает в том случае, если программисты не договорились о величине «таба», но готовы работать с кодом друг друга, имеющим разные отступы. В этом случае код и комментарии никогда не будут ползти, и для сохранения такого стабильного внешнего вида не нужно будет всякий раз переключать настройки редактора. Проблема в этом случае возникнет лишь при слиянии блоков кода, выполненных разными программистами, в одном файле.
Различия в поведении пробелов и табов
Рассмотрим следующий показательный фрагмент кода:
If (mStatus != Status.PENDING) {
switch (mStatus) {
case RUNNING:
throw new IllegalStateException("Cannot execute task: "
+ "the task is already running.");
case FINISHED:
throw new IllegalStateException("Cannot execute task: "
+ "the task has already been executed "
+ "(a task can be executed only once)");
}
}
Мы видим, что блоки текстовых сообщений легко читаются, потому что начало каждой строчки выровнено по левому краю. Когда все отступы (и кода, и выравнивания) выполнены пробелами, то блоки текста будут выровнены всегда, на любом компьютере и в любом редакторе исходного кода (ведь при написании исходного кода традиционно применяется моноширинный шрифт с пробелами одинаковой с символами ширины). Но если размер отступов будет непривычен другому программисту, он не сможет просто так его изменить.
Если же мы будем выравнивать не пробелами, а табуляцией, то мы сами получим тот же самый вид, а вот у другого программиста, у которого редактор настроен на другую кратность табуляции, например, не 4, как у нас, а 8, строчки сильно сместятся вправо, а при кратности табуляции 2 — влево. При этом у нас неминуемо поползут вторые строчки текстового сообщения. То же самое будет происходить и с выравниванием комментариев в конце строк кода. Они уже не будут красиво выровнены по левому краю на протяжении некоторого блока, имеющего разные уровни вложенности.
Промежуточным вариантом называют создание отступов — табуляцией, а выравнивания — комбинированным методом. Начало выравнивания осуществляется табуляцией, а по достижении уровня предыдущей строки — пробелами. Минусом такого способа является относительная трудоёмкость такого метода и потенциальная путаница — ведь без включения визуализации управляющих символов, сразу непонятно, где табуляция, а где пробелы. Непонятно также, как они поведут себя при копировании в другие места кода.
Более того, вышеописанный способ не спасёт от нарушения выравнивания комментариев в конце строк. Да и не все программисты, которые впоследствии будут редактировать ваш код, поймут или примут вашу задумку.
Так как же правильно оформлять код — пробелами или табуляцией? А может и тем и другим? Давайте попробуем разобраться с этим.
История табуляции — интересные факты
Небольшой экскурс в историю. Табуляция (горизонтальная табуляция) изначально была введена ещё в механических печатных машинках для удобства построения таблиц и применялась также для создания абзацного отступа. Она и не имела жёсткого размера. Перед работой пользователь сам устанавливал нужные ему позиции табуляции с помощью специального механизма. Так же, как это сейчас можно сделать в MS Word. В результате, при последовательных нажатиях на клавишу табуляции (обозначалась как ←) каретка под действием пружины автоматически перемещалась влево по всем установленным ранее позициям, перемещая тем самым область ввода вправо.
Когда пришло время электронной техники, то, чтобы не изобретать велосипед, её стали делать по образу и подобию печатных машинок. Тем более что вначале эта техника мало чем от них отличалась. Например, телетайп был фактически симбиозом телеграфа и пишущей машинки. Поэтому его разработчики просто перевели все её клавиши и некоторые другие элементы (возврат каретки, перевод каретки на новую строку и зачем-то даже сигнал достижения конца строки) в коды ASCII. Клавише табуляции был присвоен код 9, но поскольку эмулировать механизм установки пользовательских позиций табуляции было сложно, то его решили просто сделать фиксированным.
Почему же выбор размера фиксированной табуляции пал именно на 8 знакомест? Как правило, печатные машинки имели длину строки 80 знакомест. Телетайпы, применявшиеся в первых ЭВМ для вывода информации, тоже, поскольку являлись наследниками пишущих машинок. Даже на перфокартах информация стала храниться строками по 80 символов. Таким образом, печатные машинки задали некий стандарт на длину строки.
Поскольку в первую очередь табуляция использовалась для создания колонок таблиц, то наиболее удобный размер должен был быть не меньше разницы в длине наиболее употребительных слов, если их писать в столбик (чтобы для перехода к следующему столбцу не надо было делать разное число табуляций). В то же время, размер этот должен был позволять делать максимально возможное количество столбцов. Третье условие — размер должен укладываться в длину строки 80 символов кратное число раз.
Согласно последнему условию, у разработчиков был выбор из следующих пяти реальных вариантов: 4, 5, 8, 10 и 16. Первые два варианта были не очень удобными, поскольку разница в длинах слов английского языка часто превышала эти значения. Отступы в 16 символов выглядели чрезмерно большими, снижали удобство пользования этим инструментом и сильно ограничивали число столбцов в таблицах. Оставался выбор между 8 и 10 символами.
Значение в 8 символов стало первым значением, которое удовлетворяло условию разницы длин слов. Кроме того, только оно и удовлетворяло второму условию — построения максимального возможного числа столбцов. Вариант с табуляцией в 10 символов выглядел неоправданно расточительно и давал всего 8 столбцов, что могло несколько сузить сферу применения табуляции. Кроме того, число 10 для максимального количества столбцов психологически выглядело более внушительно. Все эти причины, видимо, и склонили разработчиков телетайпа к табуляции именно в 8 символов.
Несколько слов про абзацный отступ, поскольку он тоже проходит где-то рядом с нашей темой. Согласно ОСТ 29.115-88, при печати на пишущих машинках абзацный отступ должен быть равным трём ударам, но допускается использовать отступ и в пять ударов. Кроме того, предписывается размещать на одной странице 29 (+-1) строк (что примерно соответствует полуторному интервалу на печатной машинке). Требование отступа в 3 удара при полуторном интервале довольно странное, и ниже я объясню, почему.
В типографической вёрстке абзацный отступ равен полуторному размеру кегля шрифта, то есть, грубо говоря, вертикальному размеру строки (т.е. расстоянию от низа одной строки до низа другой), умноженному на 1,5. Поскольку в типографической вёрстке полутроный интервал почти не используется, а строчки следуют сразу одна за другой, то правильный абзац в этом случае приблизительно равен трём средним символам кириллицы.
Вероятно, составители ОСТ 29.115-88, не вдаваясь в подробности типографики, приняли это значение за константу и для моноширинных фиксированных шрифтов печатных машинок, и вместе с тем установили стандартом полуторный межстрочный интервал, поскольку при моноширинном шрифте и низком качестве печати одинарный интервал смотрелся реально очень плохо.
Но увеличенный интервал, исходя из правил типографики, требует и увеличенного абзацного отступа. На момент составления стандарта такой увеличенный отступ в 5 ударов уже интуитивно широко использовался. Видимо поэтому в стандарте и был узаконен применявшийся де-факто увеличенный отступ в 5 ударов.
Кстати, печатные машинки оказали влияние не только на количество столбцов текстового режима монитора, но и на его вертикальный размер в 30 строк. Ведь при печати с полуторным интервалом именно столько строк и вмещалось на один лист!
Стратегический взгляд на решение проблемы
Конечно, наиболее логично делать отступы уровней вложенности кода табуляцией, потому что она изначально для этого и предназначена — начинать печать текста с разных позиций. Кроме того, в эпоху компьютеров символ табуляции очень хорошо подошёл и на роль логического делителя. Количество последовательных символов табуляции чётко указывало уровень логического вложения.
Отсюда становится очевидным, что пробелы — это вынужденный костыль. Ведь, к сожалению, размер табуляции для каждого языка жёстко не зафиксирован. Программисты переходят с языка на язык, зачастую сохраняя традиции прежнего языка, да и свои предпочтения. В этих условиях, пробелы — мера для фиксирования внешнего вида исходника, защита от расползания его форматирования.
Выходом могла бы стать принудительная привязка размера табуляции к языку программирования. Специалистами по эргономике могли бы быть чётко определены наиболее удобные размеры табуляции для синтаксиса каждого из языков, и этот размер мог бы быть зафиксирован в компиляторе, выдавая настойчивые предупреждения при его нарушении.
Поскольку мы не можем повлиять на стратегию решения проблемы, мы вынуждены как-то выкручиваться тактически в рамках имеющейся реальности. Чтобы выработать для себя правильный вариант, давайте рассмотрим проблемы пробелов и табуляции чуть подробнее.
Проблемы пробелов
Когда программист открывает чужой исходный код с отступами и выравниванием, осуществлёнными пробелами, но отступ этот оказывается неудобен ему, он, по сути, ничего не сможет сделать для приведения его к удобному виду без проведения каких-то сложных манипуляций.
Другой проблемой пробелов являются ошибки, связанные со случайным удалением одного из пробелов отступа, оказывающиеся незамеченными. При переходе на новую строку редактор автоматически создаст тот же ошибочный отступ, что и у предыдущей строки, и эта ошибка может распространиться на несколько строк кода. Исправление этой ошибки потребует определённого времени, потраченного на унылые, чисто механические операции.
Кроме того, для удаления лишнего отступа вместо привычного нажатия на Backspace приходится нажимать сочетание клавиш Shift+Tab. Но это уже, конечно, дело привычки.
Проблемы табуляции
У табуляции только одна проблема — при изменении её размера нарушается выравнивание комментариев и других выровненных элементов, хотя их, как правило, не так много, чтобы это затрудняло чтение исходника, да и подправить их уже не так сложно.
К тому же, никто не мешает просто включить в редакторе тот размер табуляции, который был установлен у автора, сведя внешний вид к тому, который был бы, если бы исходный код был просто отформатирован пробелами. Специально для таких случаев некоторые программисты пишут в верхнем комментарии к коду рекомендуемый размер табуляции — на мой взгляд, очень правильное решение.
Выводы
Сначала скажу пару слов о размере отступов, как таковых. Применительно для большинства распространённых языков программирования идеальным размером отступов является ровно 4 символа. Почему ровно? Потому что уже сложилось так, что большинство исходников отформатированы именно таким образом, и тонкая подгонка под субъективный «идеал» в 3 или 5 символов теряет смысл.
Встречающиеся иногда отступы в 8 символов делают код излишне размазанным по горизонтали и совсем не оставляют места для комментариев справа. Кроме того, из-за превышения размера отступов над длиной операторов, в ступеньках лесенки вложенности обнажаются пробелы между операторами и операндами, которые создают визуальные провалы, что никак не идёт на пользу читабельности кода.
Также не очень хорошим решением является использование отступов в два символа, что тоже встречается. В этом случае, хотя и экономится место по ширине, но становится довольно затруднительно ориентироваться в уровнях вложенности, что неизбежно вызывает ускоренное утомление.
Если программисты будут придерживаться золотой середины в 4 символа, то спор между сторонниками пробелов и табуляции станет неактуальным. А пока можно дать следующие рекомендации:
Если несмотря ни на что вы твёрдо намерены использовать своё количество символов в отступах, то в этом случае использование пробелов и табуляции обязательно будет зависеть от того, как впоследствии будет использоваться ваш код другими программистами.
Если для обычного сопровождения в плане исправления ошибок — наверное, лучше использовать пробелы. С вашим кодом будут работать недолго, и если он хорошо отформатирован, то особой нужды в изменении размера отступов ни у кого не будет.
Если вашим кодом будут активно пользоваться другие программисты, вставляя его в свои программы или просто развивая ваш проект, то лучше использовать табуляцию. В этом случае другому программисту будет проще адаптировать вид вашего кода к принятому в той или иной группе стандарту.
Если у вас одно, а нужно другое
Есть такой замечательный редактор — Notepad++. В нём замена табуляции на пробелы и наоборот выполняется одним щелчком мыши, сделанным разделе в меню «Правка → Операции с Пробелами». Я использую этот редактор для перегона табулированных кусков кода, предназначенных для публикации в блоге, поскольку последний автоматом меняет один знак табуляции на один пробел, что неприемлемо.
Заключение
Многие могут задать вопрос, а что же выбрал для себя автор этой статьи? А выбрал он табуляцию размером 4 знакоместа. Я не нашёл достаточно веских причин для использования пробелов ради того, чтобы мой код открывался у кого-то, кто не соизволил настроить отступ в своём редакторе кода на де-факто стандарт в 4 символа.
Что касается Notepad из состава Windows, который не имеет настройки размера табуляции, и прочих подобных редакторов, делающих табуляцию принудительно в 8 символов, то я не могу себе представить причину, по которой программист открывал бы мой код именно в них, тогда как уже давно для всех ОС существуют удобные специализированные редакторы для исходного кода.
Работать в блокноте не круто. Круто работать в шестнадцатеричном редакторе:)
