Pull to refresh

Comments 143

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

крылья, ноги… главное хвост с полом определиться :)
UFO just landed and posted this here

а) Табы и пробелы отображаются у всех по разному(у меня размер таба = 2 пробела, а стандартный = 4) поэтому в больших компаниях создают / используют Coding Conventions с целью на пробелы(т.к. гораздо сложнее следить чтобы у всех всё было "правильно")
б) Одна из самых популярных code style'ов, которые может использовать любая компания, вместо изобретения своих велосипедов, для улучшения качества кода является Google Code Style, который для всех языков советует использовать пробелы. (Следовательно все сотрудники гугл используют пробелы), а бОльшая часть open source проектов на них ссылается
в) "Те странные ребята постоянно стучащие по пробелу" на самом деле просто люди, которые умеют настраивать IDE, чтобы она автоматически вместо таба ставила пробелы (например при импорте Google CodeStyle'а в любую Intellij IDE эти настройки проставляются автоматически, и разработчик даже не видит разницы)


P.s. я не вижу ни одной причины для крупных компаний использовать табы в коде, тем более и табы и пробелы, отсюда и закономерность: Большие компании с хорошим качеством кода = Пробелы => сотрудники больших компаний с хорошим качеством кода = пробелы |= зарплата

С табами еще одна проблема есть: периодически в коде приходится выравнивать относительно друг друга строки с разной идентацией, например:
if (first_part_of_long_condition() ||
    second_part_of_long_condition())
или
int class_with_long_name::method_with_long_name(type1 param1, type2 param2,
                                                type3 param3, type4 param4)
В таком коде, если написать его с табами, при изменении размера таба все развалится.

Да, спасибо. Я это и хотел сказать в первом пункте, но описал только причину и решение, вместо самой проблемы...

С табами только одна проблема: культисты не понимают когда их надо использовать и когда не надо.
Всё очень просто: для индетнации надо, для выравнивания — нет.

Вот так:
https://pastebin.com/zGcpQdss
И ничего никуда не уедет ни при какой настройке ширины табов.

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

Для поддержки такого смешанного стиля придется подсвечивать табы и пробелы, а выглядит это не очень. О пробелах проще договориться.


Если использовать для соответствия кодастайлу


  1. автоматическую конвертацию пробелов в табы при открытии файла и
  2. обратную при сохранении файла

то IDE такие участки поломает.

Поэтому не надо допускать культистов до кода в приличных проектах.
Не культистам почему-то подсветка вайтспейса не мешает и даже помогает.
И никаких костылей с конвертациями почему-то не нужно.

А кто такие культисты? Это какой-то слэнг?

https://en.wikipedia.org/wiki/Cargo_cult_programming

После чего ещё и подчищать за IDE при переносе, когда вставила не то и не туда. Двадцать лет назад кому-то где-то было очевидно. но более 20 лет назад вполне пользовались пробелами без табов и спокойно работали.

Если у Вас такие функции то уже никакой Code Style не поможет.
А в первой строчке запрещено ставить табы?
image
Мне кажется как раз выравнивание табами это еще одна их сильная сторона — если приходиться изменять выровненный текст, то в случае с табами заново выравнивать придется меньше.
Поставьте размер таба == 2 пробела и удивитесь. Для отступов — табы, для выравнивания — пробелы.
Я не вижу принципиальной разницы между этими тремя правилами:
— использовать только пробелы;
— только табы и они фиксированной ширины;
— для отступов — табы, для выравнивания — пробелы.
Чтобы все у всех было хорошо достаточно одного из трех.

Поставьте размер таба == 2 пробела и удивитесь.
И будет не выровненный код в первой строке, как обычно выглядит даже при использовании пробелов в большинстве кода что я встречал (в смысле мало кто выравнивает вообще). К тому же есть функции конвертации одного стиля в другой, но табо-пробельного я не встречал, если Вы так программируете, то наверное и знаете такие. И это происходить должно один раз при импорте стороннего кода в проект, а в проекте уже одно из трех правил выше.
Работал в одной компании, где code conventions предусматривали смешанное использование пробелов и табов. Долго воевал за пробелы, но аргумент от тимлида был — у каждого свои настройки табов, которые ему удобны, и мы должны уважить каждого. Достаточно сложно было контролировать правильную расстановку, но ничего не ехало. Но я все-таки предпочитаю пробелы, так как создавать самому себе лишние сложности в виде контроля расстановки табов и пробелов вместо сосредоточения на написании кода как такового — такое себе занятие.
<tab>int class_with_long_name::method_with_long_name(type1 param1, type2 param2,
<tab>                                                type3 param3, type4 param4)

Ну я так понимаю, начальный таб IDE сама вставляет. Получается, неудобство в том что надо много пробелов вручную добавлять, раз они теперь табом не вставляются.
Предлагаю решение — сделать общепринятый хоткей Shift+Space, который будет вставлять 4 пробела) Или 2, или 8. А таб использовать для логического отступа, для чего его обычно и нажимают.

Да, в целом как вариант. Но я сейчас преимущественно пишу на python, поэтому обозначенная проблема отпадает сама собой.
Поддерживаю! Это косвенно показывает опыт работы с чужим кодом. Давно надоела пляска с отступами в разных средах. Всегда залезаю в настройки системы, а там вместе с отступом включаю и автозамену табуляции пробелами (если есть возможность).
Карго культ силён в демагогах.

а) Зачем кому-то нужно чтобы у всех всё отображалось одинаково?
Может ещё набирать людей одного роста, пола и цвета кожи и чтобы с абсолютно одинаковыми интересами?
И имена запретить использовать, обращаться только по идентификационному номеру.
А то вдруг индивидуальность проявится, а там недалеко и до бунта, забастовки, теракта и революции.

б) А ещё гугл когда-то не делал бекапы и устроил пожал в своём датацентре. Наверное потому что они самые умные в мире.
Поэтому срочно всех разработчиков переводим на виндовс и на обед выдаём кокаколу.
Ведь миллиарды мух не могут ошибаться.

в) Именно те самые разработчики, которые не видят разницы, и являются проблемой для тех, кто видит.
И именно из-за того, что таких развелось очень много, в некоторых компаниях вводят пробелы в практику.
Это оказывается дешевле чем научить эту толпу настраивать отображение whitespace.

Итого, аргументы за табы: занимают меньше байтов и настраиваются для удобства и нет проблемы с копипастом (да, редактор сам сконвертирует пробелы в случае чего, а вот с пробелами это сработает только если их количество на отступ одинаково, что бывает не всегда).
Аргументы за пробелы: миллионы мух и непонимание табов.
Коммент был не мне, но все же отвечу.
Нужно, чтобы у всех отображалось читабельно, не обязательно одинаково. Посмотрите на пример кода из моего коммента чуть выше — если его написать с табами, выравнивание будет плавать в зависимости от настроек редактора. А что, если два таких куска кода в одном и том же файле написали два разных человека, и у одного таб был размера 2, а у другого — 8?

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

Ну, тут уж каждый выбирает, что ему важнее в проекте.
А что если включить голову и понять что «для отступов табы, для выравнивания пробелы»?
И внезапно ничего никуда больше не плавает, но настроить отступы всё-равно можно.

Итого аргумент против допуска к коду людей, не понимающих чем отступ отличается от выравнивания.
И это уже не говоря о том, что

int class_with_long_name::method_with_long_name(
︹type1 param1,
︹type2 param2,
︹type3 param3,
︹type4 param4
)

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

Вот только я не знаю ни одного тула, который мог бы автоматически проверить это правило, и не уверен, что они вообще существуют. Значит, правило будет проверяться вручную, а проверка расстановки whitespace символов вручную — не самое приятное занятие — оно отнимает время (которое куда дороже тех пары мегабайт места), снижает мотивацию команды, и тд.
Так что на практике, скорее всего, это правило, даже если будет задекларировано, не будет проверяться никак. А если учесть, что все мы люди и все иногда ошибаются, в кодобазе постепенно будет копиться код, в котором пробелы и табы расставлены неправильно, причем я уверен, что в компании из хотя бы пары сотен человек такое будет случаться каждый день. Так что да, это решение, но нереализуемое для более или менее приличного размера команды, и довольно дорогое.

Ну, в любом случае, каждый выбирает для себя то, что ему важнее. Может, вам и правда каждый байт дискового пространства для хранения кода стоит кучу денег?

PS: А насчет того, что параметры лучше в один столбец писать — откуда вам знать, может, они по смыслу сгруппированы?
Любой тул для проверки кодстайла можен быть сконфигурирован для проверки любого правила.
Внедрять в крупной компании тул, который почему-то никто не может настроить — отличный пример культизма.

А насчёт PS — я здравый смысл ещё не пропил чтобы понять логику этих параметров.

Расскажите пожалуйста, как вы предполагаете проверять, правильные ли для куска кода отступы или нет? Ведь для этого нужно 1) понимание кода и 2) понимание, что с чем автор хотел выравнять. Это как минимум не тривиальная задача. И мне не известно ни одного инструмента проверки кода, который бы это уже умел делать.

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

clangFormat мало того, что умеет так делать, так ещё и существует.

На моей практике проблемы с данным подходом возникают редко. И сразу видны глазу (я работаю с отображаемыми whitespace'ми уже давно. Много дольше, чем придерживаюсь системы «табы — для отступов, пробелы — для выравнивания»).

Аргумент про «будет копиться неправильный код» — это именно то, о чем говорил Goury. Тимлидам проще смириться с пробелами, чем объяснить, как пользоваться табами.
Ага, название метода в одной стороне, параметры — в другой. Всесто группировки на привычном для параметров месте они вывалились куда-то к подножью объявления. Их положение не несет никакой смысловой нагрузки, кроме той, что в одну строку бы они не влезли бы в экран.
А ещё можно так:

args = (
︹type1 param1,
︹type2 param2,
︹type3 param3,
︹type4 param4
)

int class_with_long_name::method_with_long_name(*args)
Довыровнять пробелами не мешает ничего кроме приверженности культу.
Что значит «довыровнять»? С другим размером таба милота все равно поедет, вопрос лишь в том, насколько далеко. Какая практическая польза в этом, кроме как прятать исходники на whitespace?
Довыровнять значит что для отступов нужно использовать табы, а для выравнивания — пробелы.
Если не понимаешь чем выравнивание отличается от отступа — это не ко мне.
Вы бы на вопрос о пользе ответили, а не выкабенивались.
Вы бы постарались понять, что человек донести хочет, а не вот это вот всё. Тогда и вопросы не возникли бы. Он на них, кстати, уже отвечал выше.
Вот я и стараюсь понять, ибо его примеры показывают только использование табов, без «довыравнивания» пробелами.
Польза в лучшей читаемости, что ведёт к сокращению ошибок.
Если не получается понять чем выравнивание отличается от отступов — вон из профессии.
Польза в лучшей читаемости

Выше я писал, что читаемость ваших примеров с табами уступает пробельному выравниванию и почему.

Если не получается понять чем выравнивание отличается от отступов — вон из профессии.

Вы адекватный пример «довыравнивания» можете привести или кроме этой истерики от вас ничего не получится добиться?
Он давал ссылку вот на это: https://pastebin.com/zGcpQdss смотреть надо в исходном (raw) виде.
Параметры функции разъедутся относительно первого из них.
Нет. Выравнивание там выполнено пробелами. Отступы — табами. Что тут сложного то? it's not rocket science.
Начиная со второго параметра, перед каждым стоит один таб в начале строки. И не суть важно, сколько там дальше идет пробелов, при изменении размера таба вся эта колонка едет. Вместо тысячи слов просто попробуте в своем любимом редакторе (=
У меня просто нет слов. Давайте я вам картиночками покажу, как ребёнку? Из своего любимого редактора, да. https://ibb.co/fTxMTQ
ОК, теперь разобрался, спасибо.

Тот же Bash не всегда корректно переваривает табы, да и большинство консольных редакторов принимают таб равным 8 пробелам, что ниразу не читабельно, я локально в редакторе настраиваю 4 пробела, ну а в некоторых местах у нас принято 2 пробела...


Поэтому — пробелы.

Назови мне хоть один редактор, в котором нельзя настроить ширину таба, культист.

Баш всегда корректно переваривает табы.

ed, т. к. tab stop'ы настраиваются не в редакторе, а в терминале

>> настраиваются

Культисты врут и не краснеют

По существу возражения будут? Или вы обосрались и, в очередной раз, перешли на личности?

В очередной раз обосрался ты, а не я.
И на личности сейчас перешёл ты, а не я.

И то, что такой контингент тут процветает, лишний раз подчёркивает что швабра скатилась в самое сраное днище.

Давай, покажи в ed(1P) регулирование размера таба. А по поводу терминала рекомендую ознакомиться с termcap(5) в особенности со свойствами it, ct, st,

Культисты врут и не краснеют

И на личности сейчас перешёл ты, а не я.


Ну-ну.

Что значит будут плавать? У каждого своя IDE со своими настройками, каждый видит код именно так как он настроил отображение в своей среде разработки. Так что это вообще никого не должно касаться у кого какие табы — это дело вкуса, который не уходит дальше разработчика. Или погромисты нынче бедные пошли и и работают на одной машине в блокноте вдесятером по очереди?
Тем более табуляция сохраняет пропорции в коде независимо от разрешения экрана.

А вот с пробелами как раз все плывет: кто-то любит дважды жахнуть по клавише, кто-то четырежды, кто сидит за моником 4:3, кто-то за 16: 9, а кто-то 16:10. Табуляция позволяет сохранить пропорции отступов, пробелы нет.

Детский сад какой-то. Не, ну можно, конечно, отказаться от табуляции, всех обязать печатать определенное количество пробелов в той или иной ситуации, посадить за одинаковые машины, одинаково постричь(налысо) и одеть, пришить номера на одежду, а печатать синхронно с в темпе барабанщика (или надзирателя с хлыстом) — ляпота…
А вот с пробелами как раз все плывет: кто-то любит дважды жахнуть по клавише, кто-то четырежды, кто сидит за моником 4:3, кто-то за 16: 9, а кто-то 16:10. Табуляция позволяет сохранить пропорции отступов, пробелы нет.

Детский сад какой-то. Не, ну можно, конечно, отказаться от табуляции, всех обязать печатать определенное количество пробелов в той или иной ситуации, посадить за одинаковые машины, одинаково постричь(налысо) и одеть, пришить номера на одежду, а печатать синхронно с в темпе барабанщика (или надзирателя с хлыстом) — ляпота…

По-моему, детский сад устраиваете вы. Во всех разумных редакторах и IDE есть в том или ином виде поддержка soft tab stops. Обычно никто не жмёт пробелы, а спокойно использует автоформатирование, клавишу tab для отступа и автоматическую вставку отступа после открытия блока (будь то curly braces, do/end или что-то ещё).

Я надеюсь, что вы так шутите, но всё же отвечу на ваш комментарий:


а) Зачем кому-то нужно чтобы всё отображалось одинаково?
1) Форматирование кода ведет к более быстрому обнаружению ошибок = > улучшают программу
2) Паттерн билдер и (не помню как это называется, вроде chain-call) когда метод возвращает инстанс самого объекта для конфигурирования — у меня таб = 2 символа, у кого-то 4 следовательно и по разному это всё будет выглядеть: кто-то по отсупам будет сразу видеть что это вызов всё того же билдера, а кто-то не будет понимать почему это так
3) Как заметил выше alexeykuzmin0, выравнивание параметров функции в столбик


Может ещё набирать людей одного роста, пола и цвета кожи и чтобы с абсолютно одинаковыми интересами?
Код стайл у всех должен быть одинаковый — он упрощает понимание кода. В команде более чем из 5 человек это серьёзно увеличивает производительность (например Класс с большой, метод с маленькой, константы SCREAMING_SNAKE_CASE'ом — только по названию мы видим что есть что, а IDE (в моём случае IDEA) и вовсе по кейсу делает подсказки. Если я не смогу найти класс из-за того, что он написан с маленькой буквы и потрачу на это дело кучу времени — я буду недоволен, как минимум. А про производительность команды в целом, я вообще молчу.
И да. В этом воопросе я не вижу связи с рассизмом. Не надо утрировать.

б) Не вижу как это относится к тому что компания, имеющая огромную кодовую базу и тысячи сотрудников составила и выложила в открытый доступ рекомендации по написанию кода. Если они вас не устраивают, то вы можете не следовать им, а следовать например Oracle Code Conventions или любым другим в зависимости от вашего языка. Рекомендации, на то и рекомендации, что, в основном, следование им, делает жизнь проще.
P.s. что гугл — самые умные в мире, я не говорил не слова(хотя спорить с этим я бы не стал, но это "моё личное скромное мнение"), но то что у них одни из самых больших зарплат(а это то что обсуждается в статье) и веб-сервисы, использующиеся сотнями миллионами людей — это факты.


в) Какая разница другим людям, от того что я вижу таб в два пробела, делаю таб, в два пробела и вообще использую пробелы, если я их комичу пробелами в репозиторий, а остальные их видят как захотят(либо пробелами, либо как я "псевдотабами")


То что они занимают меньше байтов — это не проблема, для компании, у которой столько кода, что ей не хватает обычного облака.
Со вторым, я поспорить не могу. Можете поискать/написать плагин, который вместо двух пробелов будет отображать 4.

Культ самолётников он на то и культ самолётников, что культисты следуют ему непонятно зачем.
Они думают что если построить храм самолёту ­— появится еда.

Но еда не появится.
И от бездумного использования гуглостиля никакие проблемы не решатся, а вот от непонимания — точно появятся новые.
Прекратите это дурацкое манипулирование своим неуместным карго культом. Здесь вам не балаган. Уважайте собеседников и приводите адекватную аргументацию.
Здесь именно балаган культистов.
Аргументация приведена многократно.
Но каждый культист-демагог считает своим долгом обосрать любую точку зрения, выходящую за рамки его культа.

До свидания.

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

Да нет, все остальные — это кучка культистов-демагогов, которые сливают любого, кто посмеет намекнуть на их неправоту и потом бегают за ним по всей швабре и рассказывают какие они все хорошие и как он ничего не умеет обосновывать.

Даже не удосужившись прочитать его железные обоснования парой каментов выше
Конечно же прочитав его железные обоснования. Но теперь надо быстро-быстро его заминусовать и посильнее обосрать, чтобы никто другой ни в коем случае не пошёл читать обоснования.

Чтобы все думали что он дурак, а культисты — самые правые.
Ни в коем случае не допустить распространения информации об отличиях отступов от выравнивания.

Правда же, гораздо проще помешать распространению знания чем пытаться научиться чему-то новому. Ведь если знание распространится — окружающие смогут понять что ты на самом деле дурак.

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


И выше в комментах ваши же комментарии:
Если не понимаешь чем выравнивание отличается от отступа — это не ко мне.

Если не получается понять чем выравнивание отличается от отступов — вон из профессии.

Я немного не понял, где тут распространение знания?

P.S. Сам использую только пробелы (исторически так сложилось). Переучиваться смысла не вижу да и не хочу. Хотя ничего против табов как таковых не имею.
>> Я немного не понял

Конечно ты не понял. Ведь прочитать ветку комментариев с начала, а не с конца, это же непосильная для твоего уровня задача.
Слишком много неуместной агрессии, слишком мало распространения знаний. Я прочитал всю ветку и понял о чем речь, я не понял возмущения. Комментарий со ссылкой, например, в плюсе, потому что там конкретный пример. Провокационные и излишне агрессивные комментарии без особой смысловой нагрузки в минусе. Всё вроде по делу.

Но ведь это же вы при намеке на вашу неправоту обзываете окружающих культистами и отказываетесь что-либо объяснять. Все что я увидел у вас: "Вот мой способ он работает". Ну да, работает. Почему вы при этом отказываетесь принимать то, что могут быть другие работающие способы то? Так что это именно вы отрицаете все остальные способы.
При этом вы умудрились заклеймить меня только за то, что я усомнился в вас — то есть сделали ровно то, в чем обвиняете местное сообщество.

аргументы за табы: занимают меньше байтов

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

Видимо существеннее это влияет на размер гит репозитория, если коммитов много. Хотя это тоже скорее всего мелочь.

Если средняя глубина отступов — 2.5 (а код с ощутимо большей средней величиной уже чуть более чем ужасен почти гарантированно), то экономия против 4 пробелов на отступ составит ~7-8 байт на строку. Куда выгоднее сокращать имена переменных, функций и классов/структур, их, в среднем, набирается ощутимо больше 8 символов на строку...

Зачем кому-то нужно чтобы у всех всё отображалось одинаково?

Чтобы не было "стихов Маяковского", читать которые значительно сложнее и чтобы код на экран помещался, а то код от таб-2-пробела после попадания в среду таб-8-пробелов станет слабочитаемым. Остальная часть вашего абзаца выглядит бредом демагога карго-культа.


устроил пожал

Гуглопожатые?


аргументы за табы: занимают меньше байтов

На достаточно большом диске в 360КБ на пробелах не экономил, а сейчас вот обязательно начну, убедили. И наплевать на удобство.


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

у меня размер таба = 2 пробела, а стандартный = 4

стандартный — 8

Обоснование минусам будет? Если вспомнить vt102, то там default tab stop — 8th column.

1. Для этого в Coding Conventions можно прописать, что tab == 4 пробела. Но вообще, это не имеет смысла — одному удобнее отступ в 2 пробела, другому — 4. И оба этих человека могут работать с одинаковым кодом и у каждого этот код будет отображаться как им удобно. Так что этот аргумент скорее за табы, а не пробелы.
2. Ну да, конечно. Их code style написан в доисторические времена и для очень большого разнообразия языков — вплоть до скриптов, которые правились в Блокноте.
3. Опять же, нафига что-то настраивать? Нажал на tab — вставился tab. И всё. Опять же аргумент в пользу табов.
P. S. Я не видел НИ ОДНОЙ здравой причины использовать пробелы вместо табов. Меня дико бесят отступы пробелами, когда кликнул мышкой — и курсор где-то в середине отступа оказался, когда каждый код выглядит по-разному (просто в одном отступы 2 пробелами, в другом — 4, в третьем вообще 8).
Одна из самых популярных code style'ов, которые может использовать любая компания, вместо изобретения своих велосипедов, для улучшения качества кода является Google Code Style, который для всех языков советует использовать пробелы

В Гугле создали язык Go в котором использование табов обязательно, лол.
Всё ж наоборот. Пробелы вместо табов программисты соглашаются использовать лишь за дополнительные деньги :)
На каждой строчке на целых 7 пробелов больше написал, в конце месяца у тебя на несколько килобайт написанного кода больше. Получи премию.
UFO just landed and posted this here
… Просветите виндовзятника: а в линухах кодировок нет?
UFO just landed and posted this here
Там просто русский текст в исходниках реже (нет 1с?). Иначе откуда взять разницу в размере от переезда на UTF-8?
При отсутствии в коде символов юникода размер не изменится. Стандартные символы даже в UTF-8 занимают один байт.
UFO just landed and posted this here
UFO just landed and posted this here
И что всё? Код состоит чуть более, чем полностью из ANSI символов, который однобайтные в UTF-8
Удивляюсь минусам. Неужели вы действительно считаете, отчеты между двумя версиями продукта с подсчетом количества добавленных/измененных строк бывает только в анекдотах?
Я такое наблюдал вживую буквально года 2-3 назад в весьма крупных (несколько тысяч сотрудников) компаниях. И эти компании все еще живы и отлично себя чувствуют в бизнесе.

Ну так табы и пробелы не влияют на количество добавленных/удаленных строк.

Как это? У одного сотрудника в IDE стоит автозамена табов на пробелы, а у второго пробелы на табы, по очереди правят один и тот же файл — и все в профите. (Кроме системы контроля версий)

Хук со стороны сервера, фиксированный общий code style и checkstyle или аналог на CI (плюс битье по рукам) — спасут мир.


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

Не захотел бы я работать в такой компании.

Потом, наверное, мило смотреть пулл-реквест какой-нибудь фичи, сливающейся в общую ветку.

Все таки имеет смысл анализировать и языки программирования. В том же Golang: Effective Go:


We use tabs for indentation and gofmt emits them by default. Use spaces only if you must.
Всё просто: карго культисты чаще врут.
Никто ведь не спрашивал справку о зарплате.
UFO just landed and posted this here
умножить низкозарплатную группу на 12

Тут ещё есть нюанс — обычно в странах, где считают месячную зарплату, её также считают после налогов (например, в России). А вот там, где считают годовую, обычно считают её до налогов (например, в западной Европе, США). В итоге все эти сравнения зарплат белыми нитками шиты.

Поэтому там и провели основной анализ по всего одной стране — США
А если я использую табы, но у меня в нотепаде по умолчанию задано заменяеть его определённым количеством пробелов — это я тогда к какой группе отношусь? )
Вам, парни, просто нужно отображение всех символов, как в Ворде — тогда и проблем не будет с определением таба, пробела, неразрывного пробела или скидывания строки
Лишняя информация, которая не несет смысловой нагрузки. Зачем вообще об этом думать?

Вопрос к защитникам пробелов.


У каждого программиста свои предпочтения. как должен выглядеть код в его среде разработки.
Кому-то нравится темными буквами на светлом, кому то наоборот. При этом байты кода будут одни и те же, это просто настройки отображения.


Тоже самое с отступами, кому-то нравится сильный отступ. кому-то приятнее. что бы было все рядом.
Если мы используем табы, то все четко, один уровень вложенности соотвествует одному табу. В среде я могу настраивать отображать таб. как два пробела или как четыре. В файле это вcеравно будет один символ таба.


Если же мы используем проблемы, то во-первых надо убедиться, чтобы среда вставляла таб проблемами одиноковой размерности. Во-вторых, я не могу настроить представление кода, как мне удобнее.


В чем же плюс пробелов?


П.С. У меня в компании стандарт кода предписывает использовать проблелы, и я их использую, но реальных плюсов я что-то не вижу.

В чем же плюс пробелов?

Можно выравнивать по вертикали строки разной длины.

Переменный размер таба поломает картину, а переменный размер «таба пробелами» повлияет лишь на тот код, который пи шет сам программист, а чужие произведения будут выглядеть так, как задумал автор, вне зависимости от настроек.
например
var result = SomeCollection.OrderBy(x => x.Id)
                           .Where(x => x.Param >= UPPER_BOUND)
                           .Select(x => new {
                                A = x.Id;
                                B = x.Param.ToString();
                           });

По-моему, ещё в Delphi 3 табы выравнивались в соответствии с предыдущей строкой, но точно уже не помню.

К тому же, такое форматирование делает IDE по нажатию ctrl+shift+F, alt+T, ⌘A+^I или на какое там сочетание клавиш у вас настроено форматирование кода по принятому у вас стайлгайду.

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

Или тут все программируют php в vi на продуктивном сервере заказчика? :)
Если будет такой тул, который сможет автоформатировать туда-обратно с сохранением семантического выравнивания — цены ему не будет.

Одно да потому… Зачем во второй и далее строках нужно ставить символ, обозначающий отступ, если там нужно выравнивание? Нет, даже не так. Зачем во второй и далее строках нужно ставить символ, обозначающий отступ от левого края, если там нужно выравнивание относительно верхней строки?
Во всех строках начальных табов должно быть ровно столько, сколько их в первой строке.

Среды разработки уже давно умеют выравнивать в соответствии с предыдущей строкой. А ещё есть такая магическая команда как автоформат.
Это надо было наверное лет 30 на необитаемом острове провести, что бы пропустить такой прорыв.
А чудодейственные редакторы выравнивают не табами/пробелами?)
Табами, пробелами, табы+пробелы. Как настроишь/как создатели посчитают нужными.
Так шо я не совсем понимаю суть срача.

Это вот когда деревья были большие, а единственной IDE были блокноты, тогда да, тогда срач был актуален, впрочем, в таком случае табуляция предпочтительнее и хардварные погромисты и прочие плисоводы это подтвердят.

С другой стороны, во всяких редакторах встречаются таки штуки, как smart spaces и прочие умные отступы, да выравнивания, кои на самом деле обычными пробелами не являются/не заполняются (думаю от редактора зависит, из того что я видел изнутри — никаких пробелов, только табуляция), а являются самыми обычными табами. Но яхз — я не спец по разработки IDE.
Табами, пробелами, табы+пробелы. Как настроишь/как создатели посчитают нужными.

Срач о том, как настроить лучше.
Просто если использовать табы, то писать вот такой код не получится:
int my_super_long\
     func_name(
     void * my_super\
     long_argument_name ar\
     g)
{

}


А разве ж это дело, когда строка в какиих-то жалких 270 символов уезжает за пределы второго экрана при настройке отображения табов на 18 пробелов.

P.S. Единственный серьёзный аргумент — желание, чтобы у всех код выглядел одинаково. Но вообще может стоит просто писать так, чтобы не нужно было выравнивать по 30 строк?
У меня среда разработки так выравнивает автоматически, каждый раз когда я жмакаю enter в пределах одной строчки. Чем она делает — мне на самом деле глубоко пофиг. В чем профит ручных пробелов в таком случае?
Тем более действительно, как тут уже многие высказались — отличает отступы (табы) от выравнивания.

Вы привели второй сильный аргумент в пользу табов — сжатие/растяжение кода на свой вкус. Первый — 1 символ, вместо n пробелов. На практике встречал 3 варианта: только пробелы, только табы и смешанный. Могу сказать, что подходит мне — пробелы, но не факт, что другим :) Хотя это уже сказано выше — у пробелов есть преимущество — это зрительная переносимость кода, можешь его открыть на работе, дома/ в блокноте, в ide — он все также выглядит одинаково. Можешь делать ревью в браузере — код выглядит одинаково. С табами этого добиться сложнее.

Всё просто. Если вы работаете в команде, то код должен отображаться у всех одинаково. Если вы используете табы, а ещё со своей любимой шириной, то код будет выравненым только у вас. У других программистов, он может разъехаться и стать нечитаемым.
Вы просто не умеете готовить табы. Они нужны для отступов. Но для выравнивания всегда нужно использовать пробелы. Пример: https://ibb.co/fTxMTQ. В итоге каждый может использовать удобную ему ширину отступа. У меня, например, она может меняться в зависимости от связки шрифт+монитор. Где-то пошире, где-то поуже. Иногда даже неканоничные значения типа 3 бывают приятны.
У пробелов есть проблема, похожая на то, что вы описали. В одном из проектов, над которыми я работаю, приняты пробелы для всего. Открываю я файл, начинаю его редактировать… А редактор облажался с определением ширины отступа и использует мои настройки. И вставляет не 4 пробела на отступ, а 2, например. Или наоборот. И такое не было редкостью. Но отображается у всех «одинаково», да. осталось только шрифт «стандартизовать» и его размер. =)
Цветовую схему еще забыли. А то все равно одинаково не получится

"У всех код должен отображаться одинаково" — выражение верно только условно. Цвет, размер шрифта, междуквенное растояние, каждый настраивает, как ему угодно. Разве есть задача чтобы все видели одинаковую картинку? Тогда и мониторы у всех должны быть одинаковые.


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


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


Внутристрочное выравнивание — там нужны проблелы, но там и другая логика выравнивания, там нет бложеных блоков, более того, там по сути "ручная" работа.


Внутристрочное выравнивание это, например, когда несколько строк с присваиванием и хочется выровнять значение по вертикале.

Внутристрочное выравнивание — там нужны проблелы, но там и другая логика выравнивания, там нет бложеных блоков, более того, там по сути "ручная" работа.

Если вещи типа многострочного списка аргументов, заполнения массивов, chain call'ов, do-нотации и т. п., то зачем там ручная работа? Настроил IDE, нажал хоткей автоформатирования и всё.

А разве не выпустили уже быстрых автоматизаторов, которые просто добавляют на каждую строку столько табов/пробелов, сколько тебе надо? Например в редакторе Scite так сделано, для AutoIt: жмём ALT+T и
вот такой код
#include <MsgBoxConstants.au3>
Example()
Func Example()
; Assign a Local variable an array containing the numbers.
Local $aNumber[8] = [4.8, 4.5, 4.3, 4, -4.8, -4.5, -4.3, -4]

; Assign a Local variable a string which will contain the results.
Local $sResults = ""

; Loop through the array: calculate the floor and format the result.
For $i = 0 To 7
$sResults &= "Floor(" & $aNumber[$i] & ") = " & Floor($aNumber[$i]) & @CRLF & ($i = 3 ? @CRLF : "")
Next

; Display the results.
MsgBox($MB_SYSTEMMODAL, "", $sResults)
EndFunc   ;==>Example

Превращается в такой
#include <MsgBoxConstants.au3>
Example()
Func Example()
	; Assign a Local variable an array containing the numbers.
	Local $aNumber[8] = [4.8, 4.5, 4.3, 4, -4.8, -4.5, -4.3, -4]

	; Assign a Local variable a string which will contain the results.
	Local $sResults = ""

	; Loop through the array: calculate the floor and format the result.
	For $i = 0 To 7
		$sResults &= "Floor(" & $aNumber[$i] & ") = " & Floor($aNumber[$i]) & @CRLF & ($i = 3 ? @CRLF : "")
	Next

	; Display the results.
	MsgBox($MB_SYSTEMMODAL, "", $sResults)
EndFunc   ;==>Example

А дальше табы твоя среда пусть расставляет любой ширины — хоть 4, хоть 2. Да пусть хоть кто ставит пробелы, а кто табы — жмём ALT+T и вуаля — весь код в привычной расстановке с табами. Autoit очень неплохо так весь код так держит в чистоте, не понимаю, почему в других языках так не сделают.
Как уже писали выше, выравнивание строк относительно друг друга таким образом не сделать

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

используешь табы — тебя минусуют на хабре — у тебя плохая карма — зарплата меньше
Как вам такая корреляция?
У меня есть единственный аргумент в пользу табов, который тут почему-то еще не упоминался. Навигация по коду стрелочками как то проще. Хотя может IDE умеют и в этом случае «симулировать» табы.
А вот почему так много людей используют только «tabs» а не «both» для меня загадка. Для выравнивания (например длинного списка аргументов функции) использовать табы плохо потому что все съедит если поменяется размер табуляции. Неужили все кто ответил «tabs» используют их и для выравнивания?
Ну у кого табы не 4? Конечно есть такие «я художник, я так вижу», ну пусть и видят все выровненное косо. И не так уж сильно все и съедет. Кроме того любой код с любыми отступами легко переводится в «твой любимый стиль» почти в любой IDE, так что никаких проблем.
Уже второй год живу с двумя пробелами на таб. Один проект в Московской бирже — Java, второй тут в Австралии — ruby (это принято, как стандарт для всей команды). Очень удобно и приятно
любой код с любыми отступами легко переводится в «твой любимый стиль» почти в любой IDE

А обратно как вернуть те части файла, которые ты не собирался менять?) Или это отличная идея для любителей мержить?
Перед заливкой в репозиторий у вас не делается реформат кода к стандарту команды?
Нет, конечно. Едва ли автоформатер лучше разработчика знает, как повысить читаемость кода.
Дык и разработчик не всегда знает как повысить читаемость кода. У одного моего программиста был кодстайл в 1 пробел. У меня личные предпочтения к табам + переносу фигурных скобок на новые строки. У моего фронтенда вера в не обязательность точки с запятой в JS. У человека который делал модули для проекта — приколы в ширину 60 символов на строку.

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

На самом деле, это показатель профессионализма (= Продукт разрабатывает коллектив, тут много взаимодействия, форматирование кода — далеко не единственный повод для разногласий.

Для этого и вводятся корпоративные стайлгайды с более или менее нейтральными правилами, без «приколов», ближе к общепринятым стандартам данной технологии. В C# скобка переносится, в JS — нет, например. Разработчик может гнуть свою линию (в рамках стайлгайда), но от этого особо никто не пострадает. Неадекватные капризы и принципиальность — это скорее признак того, что человек не работал в большом коллективе. Умение читать и писать в любом стиле вполне можно считать софт-скиллом.
Соглашусь с вами отчасти — на моем жизненном пути самый го*код (в том числе по форматированию) был у мегаопытных людей, могущих решить любую проблему щелчком пальцев.
Навигация по коду стрелочками как то проще.

Ctrl + стрелки
Какая разница что именно расставляет автоформатирование? или что кто то до сих пор вручную ставит пробелы и табы и сейчас мы обсуждаем зарплаты таких людей?

Несмотря на существование прекрасной фичи автоформатирования и автоматических средств проверки соответствия code style, всё равно находятся люди, которые умудряются смешивать пробелы и табы даже в одной строке.

А если я пользуюсь Ctrl+E,D по умолчанию и понятия не имею чего там Майкрософт по умолчанию поставили?
Значит, в ваших коммитах может быть слишком много мусора, не относящегося к, собственно, значимому коду.
Какого мусора? Пишу код, нажимаю Ctrl+E,D один раз и все. Откуда мусор?
Видимо, имеется в виду, что во всем файле может измениться форматирование.
Возможно, имелось в виду, что вы изменили все строки в файле, и, таким образом, ваш коммит затронет весь файл вместо того, чтобы затронуть лишь необходимую часть. После этого, например, blame будет работать неверно.
Именно.
Такой подход аналогичен подходу «я использую табы/пробелы/etc., но сам не знаю, что именно».
На мой взгляд, единственным реальным решением в такой ситуации является обязательное применение какого-нибудь clang-format перед коммитами.
Ничего страшного, я внимательно изучаю изменения перед коммитами и их отправкой в origin.

Стойкое дежавю. Совсем недавно пост с точно такой семантикой читал.

Да, но сколько и кто использует Enterов :-)) Как у них с зарплатами.?!
Порицаю не полный анализ.
Хочу добавить еще одно предположение относительно пика зарплат. Программист, оформивший собственную фирму, пишет себе минимальную зарплату, чтобы платить минимальный соц- и подоходный налог с нее. Остальное получает в виде дивидендов. По крайней мере, я делаю именно так.
Все-таки я не понимаю от чего столько эмоций. В любом проекте всегда должен определяется code-style и его должны придерживаться разработчики. В любом мало-мальски приличном IDE есть настройки для того, чтобы придерживаться данного стиля (табов, пробелов, брэйсов и т.д.). Не важно, коллегиально или только тимлидом принят этот стиль, если он есть, то следуй ему (или кто-то из присутствующих будет кричать в сторону того же Торвальдса на предмет того, что табы — это плохо, вместо того, чтобы просто настроить конкретно для данного проекта linux-style?). Здесь вообще речь идет о достаточно спорном исследовании, но достаточно интересном с точки зрения его существования.
Sign up to leave a comment.