LINUX.ORG.RU
ФорумTalks

Tabs vs Spaces: что по этому поводу думают linux kernel hackers

 , , , ,


1

4

Давненько тут не было холиваров по поводу извечного спора «табы или пробелы?..»

Залез тут давеча в исходники ядра и увидел, что отступы сделаны табами размером 8 символов (как и рекомендует code style), но при выравнивании аргументов функции иногда используется mix табов и пробелов, например, тут (drivers/cpufreq/cpufreq_conservative.c):

static ssize_t ignore_nice_load_store(struct gov_attr_set *attr_set,                                                                                                                         
<------><------><------><------>      const char *buf, size_t count)

Т.е. те, кто аргументируют преимущество табов возможностью самому настраивать длину таба, получат плохое выравнивание, например, в случае tab == 4 spaces:

static ssize_t ignore_nice_load_store(struct gov_attr_set *attr_set,                                                                                                                         
<--><--><--><-->      const char *buf, size_t count)                                                                                                                                    

Так почему же длина табов должна быть равна 8 пробелам?.. По мнению разработчиков ядра, вот почему:

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.

Почему в этом случае табы всё равно предпочтительнее пробелов?.. Разработчики ядра скромно умалчивают:

Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.

Помимо описания проблемы выравнивания, в code style ядра содержатся также много других лулзов, в частности:

However, there is one special case, namely functions: they have the opening brace at the beginning of the next line...
Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are right and (b) K&R are right. Besides, functions are special anyway (you can't nest them in C).

В старых версиях code style (например, 4.10) также присутствовало следующее утверждение:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

Потом упоминание мелкософта убрали, видимо, под давлением корпораций... :)

Итак, лет зе холивар бегин: что лучше, фиксированные табы длиной 8 или пробелы?..

P.S. Кстати, последний опрос по этому поводу был аж 10 лет назад, можем повторить :) Tabs vs. Spaces

★★★★☆

Последнее исправление: Sahas (всего исправлений: 2)

Не должно быть возможности скомпилировать или запустить код, если он не пропущен через ОДИН стандартный форматтер, который распространяется вместе с компилятором/интерпретатором разработчиками языка.

MoldAndLimeHoney
()

Уровень аргументации доставляет, конечно.

vvn_black ★★★★★
()

There are heretic movements that try to make indentations 4 (or even 2!) characters deep

Чтобы он сказал про три пробела?

что лучше, фиксированные табы длиной 8 или пробелы?

Пробелы. Табы длинной 8 - ужос!

goingUp ★★★★★
()

Наплевать, все равно ровняет или IDE автоматом, или клавиша TAB. Стиль оформления диктуется принятыми правилами в проекте.

Есть «за» за пробелы, есть «за» за табы.

Я лично предпочитаю пробелы (4 шт.), т.к. считаю, что в коде не должно быть символов, которые редактор отображает одинаково.

Но табы удобнее, если хочется видеть код в привычном стиле отступов, т.е. для одних табы выглядят в 8 пробелов, для других в 4.

soomrack ★★★★
()

Мда, странная логика.

  1. Выравнивать надо табами, потому что каждый может выбрать ширину таба и видеть код так, как ему удобнее.
  2. Ширина таба должна быть 8 символов, а кто юзает другую — еретики.

Я один вижу в этих двух утверждениях явное противоречие?

P.S. Пробелы рулят. Табы (хоть в коде, хоть вообще в принципе как псевдосимвол) — какой-то пережиток из дремучих времён, который пора забыть как страшный сон. Экономить по 3 байтика размера исходников на уровень отступа — какой-то маразм.

CrX ★★★
()
Последнее исправление: CrX (всего исправлений: 1)

Конечно табы.
На маленьких экранах удобно видеть отступы размером в 2 пробела, на больших в 4.
С пробелами такая опция не доступна.
Хотя некоторые жалуются на то, что у них форматирование едет, но эта проблема возникает из-за того, что некоторые путают отступы и выравнивание.
И пытаются выравнивать табами, а не пробелами.

Sorcus
()
Ответ на: комментарий от Sorcus

На маленьких экранах удобно видеть отступы размером в 2 пробела, на больших в 4.

линукс хакеры считают, что таб должен быть 8 символов и никак иначе!.. :)

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от CrX

Мда, странная логика.

Выравнивать надо табами, потому что каждый может выбрать ширину таба и видеть код так, как ему удобнее.

Вообще-то, в code style это не утверждается. Почему в ядре табы предпочтительнее, чем пробелы — хз... Я специально померил: распакованные исходники ядра 6.1.41 весят 1236Мб, а если заменить все ведущие табы на 8 пробелов, то размер увеличивается до 1442М. Много это или мало? Примерно на 17% размер исходников растёт...

Sahas ★★★★☆
() автор топика
Последнее исправление: Sahas (всего исправлений: 1)
Ответ на: комментарий от soomrack

Наплевать, все равно ровняет или IDE автоматом, или клавиша TAB.

не наплевать, если начинаешь смотреть исходники обычным просмотрщиком или в другой среде... Собственно, идея в том, что не стоит допускать миксования табов и пробелов, и этого можно избежать, ТОЛЬКО если не использовать табы в принципе

Sahas ★★★★☆
() автор топика
Последнее исправление: Sahas (всего исправлений: 1)

табы или пробелы

Tab’ы запретить, клавишу переименовать во что-нибудь более полезное, типа раскладки клавиатуры.
Пробел сделать программируемым, короткое нажатие – 1, длинное – 2, 4, 8 по вкусу.

quickquest ★★★★★
()
Ответ на: комментарий от Sahas

Почему в ядре табы предпочтительнее, чем пробелы — хз… Я специально померил: распакованные исходники ядра 6.1.41 весят 1236Мб, а если заменить все ведущие табы на 8 пробелов, то размер увеличивается до 1442М. Много это или мало? Примерно на 17% размер исходников растёт…

Поэтому надо убрать все непечатные символы: табы, пробелы и переносы строк. Это всё из-за них ядро разжирело!

hateyoufeel ★★★★★
()

Как тут не вспомнить классику в тему!..

https://www.youtube.com/watch?v=SsoOG6ZeyUI

 — Oh, my god! Your roommates are right, you hate spaces!..
 — No, no, no, no, I don't it's not hate. Hate is a strong word... Truth be told, I do have a slight preference for tabs but that's only because I'm anal and because I prefer precision...
 — Well, not to pick a fight here, but if you really care about precision, wouldn’t you use spaces? But whatever, once it goes through the compiler, it’s the same thing, right…?
 — If it’s all the same, why not just use tabs?
 — Because it could look different on other people’s computers.
 — Tabs create smaller file sizes, all right…? I mean, why not just use Vim over Emacs?
 — I do use Vim over Emacs.
 — Oh, god help us!..

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от hobbit

да там большинство опросов какие-то унылые...

Давай замутим батл «Табы vs пробелы» :) Вне очереди

Sahas ★★★★☆
() автор топика

Умели же раньше документацию писать, не то что нынешнее поколение неженок.

// Сторонник 4 пробелов.

urxvt ★★★★★
()
Ответ на: комментарий от quickquest

Для пробела поставить педаль под столом: легкое нажатие на педаль - 2 пробела, средее - 4, газ в пол - 8. Настоящие линух кернел хацкерс будут выжимать педаль по полной. Можно еще одну педаль добавить с табами для любителей миксовать, вот они постоянно дрифтовать будут для выравнивания.

Khronos
()
Ответ на: комментарий от Sahas

Вообще-то, в code style это не утверждается. Почему в ядре табы предпочтительнее, чем пробелы — хз…

Ну, обычно это единственный аргумент сторонников табов.

Я специально померил: распакованные исходники ядра 6.1.41 весят 1236Мб, а если заменить все ведущие табы на 8 пробелов, то размер увеличивается до 1442М. Много это или мало?

Много это или мало — вопрос, конечно, субъективного восприятия. Но так ли это важно хоть кому-то, сколько они весят в распакованном виде? В архиве — понятно — больше трафика и т.д. Но в распакованном виде… Ну да, активные разработчики ядра имеют их в распакованном виде. Но я очень сомневаюсь, что хоть одному из них важны эти 200 МБ. А кому такое важно, обычно просто юзают ОС с прозрачным сжатием и экономят намного больше.

CrX ★★★
()
Ответ на: комментарий от CrX

Но так ли это важно хоть кому-то, сколько они весят в распакованном виде? В архиве — понятно — больше трафика и т.д.

померил в сжатом tgz виде: табы — 216М, пробелы — 225М. Увеличение размера на 4%

Sahas ★★★★☆
() автор топика

почему же длина табов должна быть равна 8 пробелам?

В сочетании с ограничением в 80 символов в строке может быть способом умерить пыл любителей глубокой вложенности.

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

В сочетании с ограничением в 80 символов в строке может быть способом умерить пыл любителей глубокой вложенности.

exactly

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

померил в сжатом tgz виде: табы — 216М, пробелы — 225М. Увеличение размера на 4%

хм… Странно. Я, честно говоря, думал, что с пробелами даже меньше выйдет. Но в любом случае, 9 МБ это ни о чём.

CrX ★★★
()

весь форматтинг давно автоматизированные утилиты делают при сохранении, если проект не твой - юзай их .clang-format. В своих проектах лично я юзаю west const 4 пробела

ac130kz ★★
()

Только пробелы. Одними табами обойтись нельзя, о чём и говорится в цитатах, а значит будет мешанина из табов и пробелов и код размотает на любых настройках отличных от автора.

Форматирование табами это пердунский стиль из прошлого тысячелетия.

ox55ff ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

Форматтеры сосут со свистом. К моему большому огорчению. В qtcreator/шланге 100500 опций, через которые продраться невозможно уже в силу их количества, и хрен пойми какая что делает, и главное – хрен пойми как ей объяснить, чтобы она не форматировала вот такое:

   auto x = someLongFunctionName([&]{
       ...;
       ...;
       ...;
   });

вот так:

   auto x = someLongFunctionName([&]{
                                        ...;
                                        ...;
                                        ...;
   });

Вконец задрала, чуть ли не на каждый введённый символ ломает мне форматирование.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)

А ещё в linux управление памятью всё ещё проще, чем в BSD.

Shadow ★★★★★
()

Потом упоминание мелкософта убрали, видимо, под давлением корпораций… :)

Вообще непонятно, откуда такое неприятие венгерки у разработчиков Linux, ведь она помогает быстро понять какого типа рассматриваемая переменная программисту.

the compiler knows the types anyway and can check those

Так в том и смысл что КОМПИЛЯТОР знает и хрен с ним что он знает. ПРОГРАММИСТ не знает, в этом соль. И там где с венгеркой он просто посмотрит на имя переменной и всё поймёт – без венгерки он должен будет искать объявление и смотреть какой там тип. А это ВРЕМЯ. А время – ДЕНЬГИ.

видимо, под давлением корпораций… :)

Нет, просто им стало стыдно что подобный слабоаргументированный юношеский максимализм находится в официальной документации.

EXL ★★★★★
()
Ответ на: комментарий от buddhist

Не вижу проблемы: indent

Да тут проблема как минимум в indent, потому что это отстойный форматтер на корявеньком парсере: https://git.savannah.gnu.org/cgit/indent.git/tree/src/parse.c

Который сломается на витиеватом коде ядра Linux на каких-нибудь макросах. В случае с Linux нужно применять какую-нибудь связку из clang-format и clang-tidy, которые отстроят AST и корректно разметят тебе код хоть в K&R, хоть в Allman, хоть в наркоманский GNU.

EXL ★★★★★
()
Ответ на: комментарий от CrX

Табы это не про экономию байтов, а про настраиваемость отступов в любую нужную тебе длинну без изменения самого кода.

EXL ★★★★★
()

при выравнивании аргументов функции иногда используется mix табов и пробелов, например, тут (drivers/cpufreq/cpufreq_conservative.c):

И это явная ошибка, использовать TAB’ы не для отступов, а для выравниваний. В примре с этим файлом табы нужно заменить на пробелы, тогда выравнивание будет корректным на любом размере TAB’а.

EXL ★★★★★
()
Ответ на: комментарий от urxvt

Умели же раньше документацию писать, не то что нынешнее поколение неженок.

Ахеренно написали документацию, ага. Да так что программисты ядра Linux теперь миксуют табы и пробелы при выравниваниях, а код ядра превращается в кашу на табах отличных от размера в 8 пробелов, чем перечёркивается всё преимущество табов над пробелами.

Документация уровня ГОСТов, которые требуют выравнивания по шрифту Times New Roman из Microsoft Windows.

EXL ★★★★★
()
Ответ на: комментарий от Nervous

В сочетании с ограничением в 80 символов в строке может быть способом умерить пыл любителей глубокой вложенности.

Я склоняюсь к тому, что это породит идиотизм когда будет такая неудобная хрень:

{
    if (some_thing_shit) {
        some_long_long_name_var = 
             some_long_long_name_function(some, a_long, a_long, a_long, a_long, list, of, 
                 function, arguments);
    }
}
EXL ★★★★★
()
Ответ на: комментарий от buddhist

Очевидно, что код ядра не должен быть витиеватым.

А ещё он должен строго соблюдать стандарт C и НЕ использовать наркоманские и забористые расширения GNU, которые не допускают возможности нормально скомпилировать ядро Linux с помощью компиляторов отличных от GCC, таких как Clang, tcc, Intel C Compiler и кучи других.

EXL ★★★★★
()

Главная беда табов что у них нет фиксированного размера относительно размера пробела, у кого там размером в 1 пробел у кого 4 у кого 8. Это просто убивает его нужность в коде и красоту типа меньше байт на разметку. Хотя каждый пусть пишет как ему удобнее, а когда надо просто автоформатирует код в то что надо. Пробелы универсальнее.

code style

Вообще значения не имеет.

LINUX-ORG-RU ★★★★★
()

Вообще говоря, иметь в одном файле два вида пустого места, которые визуально друг от друга никак не отличить, а значит, нельзя понять, где что — это фигня нездоровая. Ящетаю, что должен остаться только один, а так как одними пробелами обойтись можно, а одними табами вряд ли — то на выход пойдут табы.

Nervous ★★★★★
()
Ответ на: комментарий от EXL

Ещё и об эту жесть глаза ломать? %) Нет, товарищ Барсиков, автозамена табов на пробелы и автоудаление лишних пробелов на концах строк — наше всё.

Nervous ★★★★★
()
Ответ на: комментарий от ratvier

Особенному языку — особенный редактор, логично же. Будет особенно канонично, если он будет написан на Whitespace.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Nervous

Ещё и об эту жесть глаза ломать? %)

Она включается когда нужно посмотреть в чём там траблы с разметкой. И не обязательно там где используют TAB’ы, но полезно и для пробелов, понять сколько их в той или иной ситуации с выравниванием чего-либо.

EXL ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)