Спор „пробелы против табов“ имел под собой хоть какие-то логические основания, когда IDE не умели с ними работать: надо было нажимать много раз пробел или бекспейс (при использовании пробелов), выравнивание ломалось при смене размера таба (при использовании табов).
Сейчас IDE умеют работать с табами, а люди до сих пор не научились.
Главный плюс табуляции — семантичность. Это символ, специально созданный для отступов.
Когда вам нужно поставить ссылку, вы же пишете <a href="…">, а не <span onclick="…"?
Наверняка, каждого более-менее технически подкованного человека бесит, когда в ворде отступ параграфа сделан не отступом параграфа, а пробелами (скачайте пару первых попавшихся рефератов). Но при этом такая же ситуация у себя в коде людей не бесит :-)
Все остальные аргументы теряют свою важность перед смыслом: размер файла, можно конфигурировать ширину, выглядит одинаково — вы серьёзно?
Самый разумный и естественный метод отступов — это смарт-табуляция: табы для отступов, пробелы для выравнивания:
Если среда разработки не понимает смарт-табуляцию и не может автоматически понять, где вставить табуляцию, а где пробел, то грош ей цена, такой среде.
Вот скриншот из настроек джетбрейновской Идеи:
«Чаще всего табуляция встречается в языке С, а пробелы — в Java. „
Откуда такой вывод? Я в таблице явно вижу, что чаще всего табуляция встречается в Go, практически 99%.
Просто самих проектов на Си пока что в выборке больше, чем на Go.
Клянусь, на данный момент я не знаю ни одной системы контроля версий, которая не умеет в диффах игнорировать различия в пустых символах.
Это, конечно, не оправдание для смешения разных стилей стилей в одном проекте или (того хуже) файле. Если такая ситуация при слияниях встречается у коллег по одному цеху — в цехе явно проблемы.
Проблема «табы vs пробелы» это локальная проблема общих настроек IDE у команды, а не глобальная. Связанная она с репозиторием кода, очень сложно мержить и ревьювить код когда там весь диф «красный» из-за разных настроек отступов у колег по цеху. Поэтому холивар, считаю, бестолковый на уровне религии и астрологии.
Надо дальше развивать эту мысль, лишние символы требуют больше места на дисках, т.е. требуется больше дисков, а значит, и больше электроэнергии. Плюс, производство дисков, плюс их утилизация, плюс добыча и сжигание углеводородов. Сделать расчёт, обоснование, отправить это в Гринпис, и начать всемирную войну с пробелами.
Я из «пробельщиков», но задумался вот над чем: так весь вопрос только в том, что табы в разных IDE занимают разное пространство?
И из-за этого были написаны десятки статей на хабре?
Как по мне проблема высосана из пальца, full-stack может быть человек, у которого есть огромный опыт, зп такого человека, если у него успешная карьера, соответственная, да еще может быть куча претензий к работе, которую он хочет делать. Как по мне, full-stack может называться полноценный архитектор, у которого есть знания и умения делать от и до, хотя он может уже не разбираться во всех нюансах технологий, но он может точно сказать, людей какой специализации стоит искать, а это самое главное.
А все эти full-stack меньше 3 лет опыта, это конечно, из разряда хочу знать всё. С другой стороны, если человек 5 лет назад писал на С++ совсем не факт, что его экспертиза на современном рынке сравним с теперешней, и чтобы влиться в современные технологии ему еще потребуется 2-3 месяца на раскачку.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
Вполне понял, дело в том, что даже при командной работе совсем непросто выяснить ответы следующие вопросы:
— что мы делаем?
— для чего мы это делаем?
— а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?
Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.
Закрыл для себя этот вопрос давным-давно.
Спор „пробелы против табов“ имел под собой хоть какие-то логические основания, когда IDE не умели с ними работать: надо было нажимать много раз пробел или бекспейс (при использовании пробелов), выравнивание ломалось при смене размера таба (при использовании табов).
Сейчас IDE умеют работать с табами, а люди до сих пор не научились.
Главный плюс табуляции — семантичность. Это символ, специально созданный для отступов.
Когда вам нужно поставить ссылку, вы же пишете
<a href="…">, а не<span onclick="…"?Наверняка, каждого более-менее технически подкованного человека бесит, когда в ворде отступ параграфа сделан не отступом параграфа, а пробелами (скачайте пару первых попавшихся рефератов). Но при этом такая же ситуация у себя в коде людей не бесит :-)
Все остальные аргументы теряют свою важность перед смыслом: размер файла, можно конфигурировать ширину, выглядит одинаково — вы серьёзно?
Самый разумный и естественный метод отступов — это смарт-табуляция: табы для отступов, пробелы для выравнивания:
Если среда разработки не понимает смарт-табуляцию и не может автоматически понять, где вставить табуляцию, а где пробел, то грош ей цена, такой среде.
Вот скриншот из настроек джетбрейновской Идеи:
https://github.com/maximal/tab
https://www.emacswiki.org/emacs/SmartTabs
Откуда такой вывод? Я в таблице явно вижу, что чаще всего табуляция встречается в Go, практически 99%.
Просто самих проектов на Си пока что в выборке больше, чем на Go.
Я не написал, что обязательно игнорируют разницу в белых символах, я написал, что умеют игнорировать.
Клянусь, на данный момент я не знаю ни одной системы контроля версий, которая не умеет в диффах игнорировать различия в пустых символах.
Это, конечно, не оправдание для смешения разных стилей стилей в одном проекте или (того хуже) файле. Если такая ситуация при слияниях встречается у коллег по одному цеху — в цехе явно проблемы.
А я думал, что похоливарили и перешли на табы. ;)
И из-за этого были написаны десятки статей на хабре?
А все эти full-stack меньше 3 лет опыта, это конечно, из разряда хочу знать всё. С другой стороны, если человек 5 лет назад писал на С++ совсем не факт, что его экспертиза на современном рынке сравним с теперешней, и чтобы влиться в современные технологии ему еще потребуется 2-3 месяца на раскачку.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
— что мы делаем?
— для чего мы это делаем?
— а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?
Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.