Согласно статистике Github — самыми популярными являются именно пробелы. Более того, даже имеется статистика, согласно которой якобы программисты использующие пробелы зарабатывают больше.
Сразу оговорюсь — до недавнего времени я и сам был ярым приверженцем пробелов. Однако все изменилось с изучением языка Go. Писали его очень уж умные дядьки и кредит доверия у меня к ним довольно высокий. Потому любое решение, которое не укладывалось в мое мировоззрение, я вначале тщательно исследовал и пытался понять, прежде чем кричать о том, что это все неправильно. То же случилось и с табуляциями.
Для начала я еще раз напомню основные доводы каждой из сторон этого древнего спора. Точнее те аргументы, к которым чаще всего сводились эти споры на моей практике:
Пробелы:
- У всех одинаково видны, т.е. форматирование у всех одинаковое вне зависимости от настроек IDE и прочего
Особенно удобно для блочного выравнивания, т.к. тогда изменение длины таба никак ее не собьет
var i uint64 = 10
var name uint64 = 20
Табы:
- Каждый может настроить отступы под себя не мешая другим в проекте. При этом код будет одинаковый у всех
- Объем файлов меньше
Обе стороны только одинаково понимают что мешать оба стиля в одном проекте НЕЛЬЗЯ. Хоть тут сходимся.
Если вдруг кто не знает — в Go создатели языка впилили целый пакет удобных утилит для разработки «прямо из коробки». Тут вам и компилятор, и тестировщик, и генератор документации, и многое-многое другое. Но самое интересное — это утилита gofmt, которая обеспечивает форматирование кода. И благодаря этой части пакета Go, форматирование кода у всех одинаковое, и холивары тут неуместны. Собственно в том и была идея создателей — убить холивары на корню. Но что еще интереснее — это выбор символа для выравнивания. В Go это табуляция.
Поначалу меня это очень смутило, ведь я давно был приверженцем пробелов и не ожидал что люди создавшие С, Unix и Go могли принять такое решение. Но как я уже сказал — кредит доверия к ним большой, и именно это и помогло мне перешагнуть confirmation bias, которому я как и многие подвержен в холиварных вопросах. Проблема состоит в том, что когда уже принял какую-то сторону, особенно в холиваре, то аргументы второй стороны ты слушаешь да не слышишь. Ну и голову не включаешь.
Так вот, когда включаешь голову то решение оказывается столь простым и очевидным что даже трудно понять как оно раньше в голову не пришло. А вся проблема в том самом правиле «мешать — нельзя». Так то оно так, только когда такое говорят то имеют ввиду indentation, а не alignment. В английском языке для этого два разных слова, но у нас чаще всего и то и то величают «выравниванием» (хотя indention это «отступ», но и «выравниванием» его часто называют).
Вот что делает Go. Для indention — используются табы и только табы. Пример:
func main() {
var i = 1
}
А вот для alignment — пробелы:
var i uint64 = 10
var name uint64 = 20
Сколько я ни думал, я так и не смог придумать ни одного существенного минуса в таком подходе. А вот плюсы сохраняются от обеих сторон:
- Блочное выравнивание все еще сохраняется у всех вне зависимости от настроек IDE
- Отступы каждый себе сам делает как ему удобно, не мешая другим
- Исходники меньшего размера
Лично для меня это раз и навсегда закрывает этот один из самых старых холиваров IT-мира.
Однако может я чего-то не замечаю?
UPD: Я таки и правда не замечал (точнее забыл) пару моментов, за которые я всегда предпочитал пробелы. В комментах мне на них благополучно указали:
1. В таком подходе нельзя сделать красивое выравнивание переноса длинных строк
Например в SQL запросе:
SELECT CASE WHEN val < 0 THEN 'Negative'
WHEN val > 0 THEN 'Positive'
ELSE 'NULL or zero'
END AS field_sign, ...Или же в переносе аргументов вызова функции в длинной строке:
if (object.drawRect(rectangle.x,
rectangle.y,
rectangle.width,
rectangle.height)) {
}2. Отображение кода в местах где мы не контролируем размер tabstop-а (Github, git diff, email, diff, slack, habr, etc.)
В таких случаях размер табстопа будет зависеть от настроек конкретной среды, и часто будет 8 символов, ломая всю красоту отображения
P.S. Каюсь, я был наивен решив что Go положили конец холивару крайне простым и крайне очевидным (да и часто используемым) решением. На то они и холивары…
Комментарии (91)
bisquitie
15.10.2019 05:23А меня воротит от египетских скобок.
justme Автор
15.10.2019 05:26Меня тоже. Этот момент я пока все еще не могу понять почему Go приняли именно такой стандарт
Jeka178RUS
15.10.2019 11:40Код меньше строк занимается, особенно если много if else.
if (smth){ }else{ } vs if (smth) { } else { }
За заметку спасибо, не писал на Go, но в С++ сам для себя пришел именно к такой схеме табами блоки, пробелами локальное выравнивание. Я правда смешал скобки, тела функций у меня в обычных скобках, а блоки циклов ифов и т.д. в египетскихjustme Автор
15.10.2019 13:13Я бы все равно поспорил насчет скобок… но не стану) И так развел холивар, хотя идея была именно его закрыть
Вообще, конечно, главное правило — договориться и писать в одном стиле с командой. Остальное уже не так важно
sergey-gornostaev
16.10.2019 06:58
bisquitie
16.10.2019 14:26И? Потому что одни чуваки решили сэкономить пару страничек при вёрстке совершенно не означает что теперь всем это должно нравиться.
justme Автор
16.10.2019 14:49Полностью согласен. Хотя я и преисполнен глубочайшим уважением к этим ребятам (и к авторам языка Go), но меня не покидает мысль что это не лучший выбор именно для Go.
Поясню: одной из важных идей которые пропагандирует Go при написании программ — это то, что однозначность и простота чтения должны стоять выше краткости. Т.е. они даже от наследования поведения в ООП отказались для этого (имхо — это очень здорово что они так сделали). ИМХО, но скобка на новой строке — куда понятнее и проще для чтения (не забудешь про пропущенную скобку), хотя и в ущерб краткости кода. В таком случае они вроде как этими египетскими скобками сами нарушают свои правила…
Hivemaster
16.10.2019 18:42Не просто какие-то чуваки, а создатели языка и основоположники синтаксиса, ставшего основной множества современных языков.
justme Автор
16.10.2019 18:44Да, кредит доверия к ним огромный. НО! Это не значит что не нужно задавать вопросов и высказывать сомнений
edogs
15.10.2019 05:53Холивар жестко устарел в меру наличия автоформаттеров под любой стандарт.
Тем не менее, отметим, что табы для alignment тоже имеют свою логику, отчасти даже бОльшую чем для indention, т.к. позволяют не думать сколько пробелов надо наколбасить в зависимости от длины имени переменной.
Как про личное мнение — нас годы работы с чужим кодом видимо сломали. Сначала достаточно напрягало то одно форматирование, то другое… ставили даже форматтеры, что бы писать как удобно, а в проект отдавать как надо, но постепенно стало абсолютно по фиг какой там стандарт, посмотрели — и пишем в нем.
Единственное что немного до сих пор из себя выводит, это перенос открывающей фигурной скобки на следующую строку, этож такая бездарная потеря целой строки:) А удобства не добавляет, т.к. всё равно взгляд при просмотре кода ориентируется на indention.justme Автор
15.10.2019 06:12Число табов также будет зависить от длины переменной. при чем порой даже при разнице в 1 символ
Но вообще да, холивар не столь актуален как раньше, но все же встречается частенько. Я почувствовал облегчение переметнувшись на другую сторону, т.к. закрылся старый гештальт. Решил поделиться с остальными, вдруг кому тоже покажется полезным
vintage
15.10.2019 07:05Тут уже проблема редакторов, что они выравнивают по 8-символьной сетке как в текстовых терминалах, вместо того, чтобы выравнивать все, что справа в одну колонку.
dipsy
15.10.2019 06:00А теперь включите пропорциональный шрифт в редакторе (более удобный для восприятия текста, чем моноширинный, некоторые
извращенцыперешли на него и обратно за уши не оттащишь). И тут же весь ваш alignment пробелами превращается в тыкву.
Аналогично при ренейминге, переименовываем «name» в «other_name», а таких вхождений у вас в проекте 876 штук, и везде выравнивание поплывёт, в каждом месте придется отдельно вручную править.
Не используйте ASCII-арт в коде, ни к чему это, можно и без него понятно и наглядно писать после некоторой практики. // Сугубое имхо, подтверждаемое многолетней практикой, тем не менее понимаю и принимаю какая куча минусов сейчас прилетит от любителей красиво отбитых многочисленными пробелами колоночек (до первого ренейминга), к счастью рефакторинг практикуют далеко не все из них, так что это обычно не проблема.justme Автор
15.10.2019 06:08Насчет НЕ моноширийного шрифта — это, ИМХО, какая-то ересь)))
Может во мне говорит закостенелость, но я врядли смогу такое когда либо принять
Про отступы при рефакторинге — согласен. Но тот же go fmt все правит за вас. Также читал что во многих IDE есть настройка smart tabs, которая делает ровно тоже
А колоночное выравнивание — это не ASCII-арт, а повышенное удобство чтения кода. Особенно хорошо при написании библиотечного кода либо кода с большим числов последующих разработчиков что его будут использовать/поддерживатьvvadzim
15.10.2019 09:02-1Моноширинный шрифт — это просто артефакт пишущих машинок и электроники относительно недавнего времени, когда конструктивно делать пропорциональные шрифты было невыгодно. Для чтения для большинства людей удобнее пропорциональный, обкатанный за несколько веков.
Но удобство понятие относительное и сильно зависит от привычек, а привычки зависят от обстоятельств. И на данный момент для большей части программистов удобнее моноширинный шрифт, потому что привычнее, и потому что под его фичи (выровнять пробелами в три столбца, ascii-арт) заточены недостатки современных IDE.
Фича выравнивания забавно смотрелась на заре компьютеризации, когда местный програмер-админ бил по рукам тётенькам из бухгалтерии за выравнивание пробелами в ворде, а потом отбивал пробелами свой код. С точки зрения тётенек — шиза полнейшая.
ПС Пользуюсь пропорциональным, но не разделяю стиль комментария, на который вы ответили.mayorovp
15.10.2019 09:24Фича выравнивания забавно смотрелась на заре компьютеризации, когда местный програмер-админ бил по рукам тётенькам из бухгалтерии за выравнивание пробелами в ворде, а потом отбивал пробелами свой код. С точки зрения тётенек — шиза полнейшая.
А разве код кто-то выравнивает пробелами по центру или там по правому краю? :-)
vvadzim
15.10.2019 09:28Код по правому — легко. Сам видел.
Но тётеньки и столбцы текста пробелами выравнивали.
Да что там выравнивали, два года назад (2017-й) точно скачивал с сайта налоговой форму декларации в ворде со столбцами, отбитыми пробелами. Оба стобца по их левому краю.
JustDont
15.10.2019 10:26+1И на данный момент для большей части программистов удобнее моноширинный шрифт, потому что привычнее
Но это неправда. Моноширинный шрифт при прочих равных не просто «удобнее», а читабельнее, что для программистов имеет критическое значение. Удачи безошибочно читать серии узких символов (в латинице самые прекрасные — Ili) когда шрифт не моноширинный.vvadzim
15.10.2019 10:31читабельнее, что для программистов имеет критическое значение
В точку. Читабельность тоже зависит от привычек.
Ili
Зависит от шрифта. Тот что сейчас на хабре — ой. А в моей IDE мной читается отлично.
geher
15.10.2019 10:12Насчет НЕ моноширийного шрифта — это, ИМХО, какая-то ересь)))
Не моноширинный шрофт появляется в двух случаях: необходимость редактиоования не в любимой ИДЕ, а в единственно доступном примитивном "блокноте", в котором искать пару моноширинных шрифтов то еще мучение, и при необходимости код опубликовать при некоторых ограничениях на используемые шрифты.
Ну еще есть любители таких шрифтов, которые выставляют их в своих любимых ИДЕ.
Так что решения по факту на все случаи жизни нет.
Автлматическое фооматирование не всегда доступно, а любой стандарт можно "поломать" привычными настройками редактора или вынужденным выбором неподходящего редактора.
Сам я обычно следую формату, принятому в проекте. Так проще.
justme Автор
15.10.2019 14:23Ну, первый случай — это скорее быстрая задача и вырожденный пример. Так можно и в MS Word редактировать код и жаловаться на отступы)
Второй — тоже из разряда вырожденных, как по мне. За все годы работы в IT лишь пару раз видел девелоперов юзающих не моноширийный шрифт в IDE, и те — junior-ы с опытом около года. Де факто моноширийный шрифт при редактировании кода — стандарт и в IDE-шках всех и во всех markdown редакторах с блокомПросто ставить не-моноширийный шрифт это из разряда комментария от @JekaMas: не нужно стрелять себе в ногу, и все будет хорошо))
С не моноширийным шрифтом и табы и пробелы будут плохо смотретьсяgeher
15.10.2019 19:06Ну, первый случай — это скорее быстрая задача и вырожденный пример. Так можно и в MS Word редактировать код и жаловаться на отступы)
Понятно, что в большинстве случаев сидишь в своей родной IDE, и все нормально, если не выделываться и пользоваться моноширинным шрифтом. Но случаи бывают разные. Вот и приходится терпеть и ругаться, поскольку проблема не решается везде быстрым и удобным образом по определению.
А код в MS-Word — это вопрос подготовки к публикации.
Второй — тоже из разряда вырожденных, как по мне. За все годы работы в IT лишь пару раз видел девелоперов юзающих не моноширийный шрифт в IDE
А по моему опыту что-то последнее время таких слишком много развелось.
dipsy
15.10.2019 20:45и те — junior-ы с опытом около года
Ну я например лет через 7 с начала карьеры к этому пришел и уже столько же пользуюсь. Насчет джуниоров интересно, может уже тенденция намечается и новое поколение естественным образом моноширинность забудет, как забыли квадратные пиксели в буквах, на современных дисплеях высокого разрешения буквы визуально гладкие.justme Автор
15.10.2019 21:02О боже! Как?!)))
Нет, я серьезно не могу понять, без шуток. Это ж большинство чужого кода должно начинать плыть при любом типе блочного выравнивания (блочные комменты, блочные объявления функций, блочные import-ы, перенос аргументов на следующие строки и т.д.)
И это неговоря о том что все не моноширийные шрифты что я видел не оптимизированы для программирования (нет заметного отличия 0 от O, часто слабо заметно отличие l от I, и т.д.)
А что за шрифт конкретно вы используете? Хотел бы глянутьdipsy
16.10.2019 06:16Шрифт verdana, l от
Iтам отличается, 0 от O тоже, за счет заметно большей округлости.
С чужим кодом некоторая (небольшая) проблема, да. Благо 75% времени варюсь в «своём» коде, который самолично поддерживаю и форматирую вообще как хочу, а с прочим ну прям фатальных проблем нет, за исключением некоторых особо упоротых любителей, всерьёз занимающихся ASCII-артом, всё это весело плывёт в разные стороны, но реально такого не много, единичные случаи.
sergio_nsk
15.10.2019 06:04Плохо тем, что когда садишься за другой комп или используешь другой редактор, ты тратишь время на настройку отступов по табу. И так ты делаешь в каждом редакторе. А я не трачу время, когда используются пробелы.
Когда смотришь на изменения (патчи), в почтовом клиенте, в веб-интерфейсе гитхаба, гитлаба, битбакета, в них вообще не предусмотрена настройка ширины таба, и всё выглядит паршиво с табом 8.justme Автор
15.10.2019 06:10Ну, садясь за другой комп/редактор полюбому много чего приходится настраивать под себя. Все равно это одноразовая акция и довольно быстрая к тому же
Про почтовый клиент или гитхаб — наверно, соглашусь. Но, опять же, как по мне это минимальный минус в сравнении с плюсами
petuhov_k
15.10.2019 06:40Что-то я не понял. Когда используются пробелы, вы не тратите время на настройки, потому что эти настройки не влияют. Вы вынуждены пользоваться тем форматированием, которое выбрал автор кода. Что мешает делать так-же с табами? Зачем Вы лезете в настройки? Это дополнительная возможность, которой вы точно также можете не пользоваться и не тратить «кучу времени» на пару кликов.
berez
15.10.2019 12:54+1Что мешает делать так-же с табами? Зачем Вы лезете в настройки?
Приведу пример из жизни. Пришлось как-то срочнасрочна асап фиксить баг на удаленной машине. Изо всех редакторов — только vi кондовый (не vim!). Стрелочки не работают, длинные строки не заворачиваются и уходят за край экрана, при этом размер окна терминала фиксированный. Размер таба тоже фиксированный — 8 символов.
Открываем файл, а там только пара строк в самом начале — дальше пусто. Оказалось, что китайский разработчик кардинально и навсегда решил для себя проблему табуляций: выставил в IDE размер таба в 1 и расслабился. А у нас в редакторе все строки уехали за край экрана и редактировать пришлось практически вслепую.justme Автор
15.10.2019 13:02Эм… а что мешает выставить tabstop в vi? Вроде настройка эта есть даже в старом-древнем vi, а уж в vim и подавно. Делается это в одну строчку в одном файле
Ну и опять же — если бы тот же самый разработчик использовал пробелы — то у вас не было бы шанса сменить на удобный вам формат в одну настройку. А уж если бы он использовал 8 пробелов — то вы бы и вовсе были в той же ситуации только с куда меньшим числом возможных путей решенияberez
15.10.2019 13:18Эм… а что мешает выставить tabstop в vi? Вроде настройка эта есть даже в старом-древнем vi, а уж в vim и подавно. Делается это в одну строчку в одном файле
Возможно, то, что нужно было подправить пару строчек, а не заниматься настройками на чужой машине.
Ну и опять же — если бы тот же самый разработчик использовал пробелы — то у вас не было бы шанса сменить на удобный вам формат в одну настройку.
Задача была — поменять пару строчек, а не заниматься переформатированием исходников для получения эстетического наслаждения.
А уж если бы он использовал 8 пробелов — то вы бы и вовсе были в той же ситуации только с куда меньшим числом возможных путей решения
Вовсе нет.
Если бы размер таба был 8 символов, текст бы не уплыл за правую границу экрана, т.к. кодинг стайлом предписывалось, что текст не должен уползать за 80-ю колонку. Т.е. в моем терминале программа бы выглядела так же, как у него в IDE, а не с километровыми отступами.justme Автор
15.10.2019 13:25Ну так если задача очень короткая — тогда и проблемы большой не было. Из мухи слона делаете, ИМХО.
Учитывая что в кодинг стайле прописывалось чтоб текст не уползал за 80ю колонку, но НЕ прописывалось при каком минимальном размере таба — то это просчет код стайлинга, которым, похоже, ваш девелопер и воспользовался поставив табстоп в 1 символ :)
Ну, просто мне бы, например, оступ в 1 символ был бы огромной болью сам по себе. Даже 2 символа — излишне мало, ИМХО. 4 пробела приучает писать строки короче, читабельнее, и избегать многомерной вложенности.
К слову — 80я колонка также может считаться уже архаизмом, хотя я тоже стараюсь его придерживатьсяberez
15.10.2019 14:59Ну так если задача очень короткая — тогда и проблемы большой не было. Из мухи слона делаете, ИМХО.
Особенно было приятно смотреть на закаленных боями любителей vim. Они выражали ровно то же ИМХО ровно теми же словами, но почему-то довольно быстро тухли, столкнувшись с суровой реальностью vi.
Учитывая что в кодинг стайле прописывалось чтоб текст не уползал за 80ю колонку, но НЕ прописывалось при каком минимальном размере таба — то это просчет код стайлинга, которым, похоже, ваш девелопер и воспользовался поставив табстоп в 1 символ :)
Спасибо, что объяснили. Теперь-то все стало понятно.
Ну, просто мне бы, например, оступ в 1 символ был бы огромной болью сам по себе. Даже 2 символа — излишне мало, ИМХО. 4 пробела приучает писать строки короче, читабельнее, и избегать многомерной вложенности.
А китаец именно так и писал — он ставил четырьмя табами отступ в четыре позиции (согласно кодинг стайлу, кстати).
Вот только его 4 таба разворачивались в 32 позиции в vi. Это к вопросу «что мешает делать так же с табами?», озвученному товарищем petuhov_k выше.
К слову — 80я колонка также может считаться уже архаизмом, хотя я тоже стараюсь его придерживаться
Довольно удобный архаизм. И в строку влезает достаточно много, и взглядом легко сопоставить начала строк с их концом. Хотя можно и подлиннее, да.justme Автор
15.10.2019 15:05Особенно было приятно смотреть на закаленных боями любителей vim. Они выражали ровно то же ИМХО ровно теми же словами, но почему-то довольно быстро тухли, столкнувшись с суровой реальностью vi.
Ну, я тоже любитель vim. Но и в vi приходилось работать, если на сервере не было доступа на установку пакетов (в противном случае просто сразу ставил vim)
Да, vi сам по себе куда менее удобен, но настройки эти там тоже имеются, так что не проблема
А китаец именно так и писал — он ставил отступ в 4 позиции (согласно кодинг стайлу, кстати).
То что китаец «странный» я даже писать не стану. А вот то что кодинг стайл странный — напишу. Т.е. получается что кодинг стайл описывал число отступов, но не описывал тип отступа? Впервые такое вижу. Это уже проеб кодинг стайла наложенный на китайские странности, так что злиться на отступы тут не к чему.berez
15.10.2019 15:18Да, vi сам по себе куда менее удобен, но настройки эти там тоже имеются, так что не проблема
Боюсь, вы не видели кондовый, исконно-посконный vi. В большинстве систем vi — это симлинк на полноценный или немножко облегченный vim. Но там был именно что суровый vi чуть ли не 80-х годов выпуска. Не сомневаюсь, что за пару дней мы бы разобрались, как в нем выставить табстопы (или собрали бы из исходников какой-нибудь другой редактор), но задача была не в этом.
И чтоб не идти на второй круг: нет, я не считаю тогдашнюю проблему с табами серьезной. Просто вспомнилось.
Т.е. получается что кодинг стайл описывал число отступов, но не описывал тип отступа? Впервые такое вижу. Это уже проеб кодинг стайла наложенный на китайские странности, так что злиться на отступы тут не к чему.
Спасибо, конечно, за ваш диагноз и мнение о том, кто виноват. Но я не просил ставить диагнозы и называть виновных. Я привел реальный случай, с которым мне пришлось столкнуться из-за того, что у табуляции бывают настройки.justme Автор
15.10.2019 15:24Боюсь, вы не видели кондовый, исконно-посконный vi.
Да уж видел. Я его лично из исходников собирал на gentoo когда-то давно. Да и во многих сборках и по сей день стоит именно vi по-умолчанию. Сейчас, правда, начали переходить на vim.minimal
я не просил ставить диагнозы и называть виновных
Как-то вы аггресивно реагируете на нормальное обсуждение проблемы. Я лишь пытаюсь пояснить что данный пример не совсем отражает суть вещей и не является достаточным аргумент в пользу или против табов. Ну и там явно не нужно «пару дней» чтоб выставить табы
На самом деле все что я пытался показать — это то, что если перешагнуть confirmation bias, то можно найти вполне очевидный вариант который имеет почти все плюсы обоих подходов и практически никаких минусов (чуть ниже Akina все же показал минус один, так что не совсем идеальное решение холивара вышло в Go)berez
15.10.2019 16:06Я лишь пытаюсь пояснить что данный пример не совсем отражает суть вещей и не является достаточным аргумент в пользу или против табов.
А разве я утверждал обратное?
Товарищ petuhov_k озвучил вопрос «что мешает обращаться с табами как с пробелами?». Я ему привел пример, когда табы от пробелов сильно отличаются в работе.
Остальная наша беседа — классический bikeshedding.
POPSuL
15.10.2019 06:31У вас почему-то в пример с табами запрятались пробелы ;)
pmcode
15.10.2019 06:36А есть вообще IDE, которые умеют в alignment? Ни одной еще не видел. Непонятно зачем с ним париться, если при первом же автоформатировании (не вашем, так коллеги помогут) все это красивое выравнивание сдует. Да и смысла с нем особого нет, если честно.
POPSuL
15.10.2019 07:31GoLand умеет, но не во всех кейсах. Структуры и const блоки выравнивает из коробки.
Заголовок спойлера
shir
15.10.2019 10:04Для vscode (то что сейчас использую) https://marketplace.visualstudio.com/items?itemName=wwm.better-align
Для vim'а такое тоже находил и для Sublime. Вот для Atom'а не помню.
smart_alex
15.10.2019 08:27В своих проектах использую пробелы и «табличное» форматирование (когда любые схожие фрагменты кода и данных структурируются в псевдо-табличную форму). Плюсы такого подхода:
1. Мгновенно становится видна «размытая» структура алгоритма
2. Мгновенно выявляются трудноуловимые ошибки «опечатки» в сходных данных. Это сэкономило мне невероятное количество времени на поиск таких ошибок — их просто не стало
3. Сразу визуально становится видно как оптимизировать алгоритм
4. Код (листинг) уменьшается в размере, иногда на порядок, и на экране умещается то, что раньше было растянуто на 10 экранов
Никого не агитирую за такой подход, но сам уже (в своих проектах) ни на что его не променяю.
musicriffstudio
15.10.2019 09:51А что такое «пробел»?
Смотрим педивикию
ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB
или английский
en.wikipedia.org/wiki/Whitespace_character
Там этих пробелов немеряно. Неразрывный пробел, отступ при сокращениях и т.п. и т.д.
Это всё из полиграфии. Правила исторически сложились и позволяют оформлять тексты красиво.
В текстовых редакторах для программистов этого богатства значений просто нет. Есть один-единственный знак «спейс», немоноширинные шрифты не используются.
С практической точки зрения в примитивных текствых редакторах для программистов единственное отличие от моноширинных пробелов — табы могут иметь разную ширину настраиваемую локально (персонально), например на широком мониторе это 3см, у кого-то обычный и он ставит 0.5см, а сам код один и тот же.
Это удобно для отступов в коде, почему, собсна, и введён символ «таб» в не-WYSIWYG редакторы давным-давно.
Обычные программисты (обычные офисные клерки тоже, кстати) этого не понимают и изобретают собственную систему обозначения отступов пробелами.
Akina
15.10.2019 10:36может я чего-то не замечаю?
Да. Есть случаи, когда отступ является и тем, и другим одновременно.
SELECT CASE WHEN val < 0 THEN 'Negative' WHEN val > 0 THEN 'Positive' ELSE 'NULL or zero' END AS field_sign, ...
В строке 4 — чистый ident, а вот в строках 2 и 3 ident до позиции CASE, а затем align.justme Автор
15.10.2019 14:19Чьорт… вы сломали мне идилию))
Да, в случае такого выравнивания пробелы все еще рулят. И это применимо не только к SQL, но и попросту при переносе аргументов вызова функции на 2ю/3ю строку
Зря я вообще полез в холиварную тему…
ded_kulibin
15.10.2019 10:36Считаю что исследование github бесполезное. Многие редакторы позволяют заменять табы пробелами (Visual Studio, например). А у некоторых такое настроено по умолчанию.
vitaliy2
16.10.2019 13:24А при сохранении возвращать всё обратно? Чтобы не было проблем с git? (ненужные изменения).
Вообще проще просто юзать tab indent space alignment, остальные методы являются ошибочными, т.?к. юзать табы для выравнивания — грубая ошибка, а юзать пробелы для отступа — тоже грубая ошибка.justme Автор
16.10.2019 15:16Согласен что использовать табы для выравнивания — ошибка, в таком подходе куда больше минусов чем плюсов
Но почему использовать пробелы для отступа — ГРУБАЯ ошибка? Да, весь пост о том что юзать табы для отступа, вероятно, имеет меньше минусов чем плюсов. Но все же, прямо ГРУБАЯ ошибка??vitaliy2
17.10.2019 21:27Во-первых, потому что это противоречит смыслу символа. Что-то типа «Почему использовать трусы в качестве футболки — грубая ошибка?». Можно, но блин, капец как странно.
Во-вторых, потому что разные люди предпочитают разный размер таба. Что им делать с Вашим документом? Причём автоматически заменить не так просто, надо распарсить синтаксис программы, это наглядно видно в этом примере:
{ const a = 5, b = 6; //Обратите внимание на эту строчку — вначале стоит таб, потом 6 пробелов. }
А даже если делать какую-то замену, будут постоянные конфликты в git + огромный геморрой людям: почему они при каждом открытии каждого файла должны делать замены, вместо того, чтобы изначально было написано правильно?
В-третьих, замену можно сделать не всегда. В браузере это будет очень проблематично. А вот размер таба легко настраивается в браузере.
В-четвёртых, это может быть удобно и для себя:
- Во-первых, ты можешь работать с разными мониторами, и на них будет разный размер отступа, чтобы код влезал или почти влезал везде.
- Во-вторых, какой-то кусок кода может начать не помещаться на экран, и тогда можно временно уменьшить размер отступа.
- В-третьих, это просто круто иметь возможность в любой момент настроить размер отступа.
В-пятых, по табу легче навигация и удаление символов. Ведь нужно понимать, что вообще для удаления редактор должен уметь хорошо парсить код, чтобы быть настолько умным, чтобы понимать, что здесь по-хорошему должны были стоять именно табы, а не пробелы (см. пример в п.?2). Либо же сделать шорткат, который удаляет нужное количество символов. Но если конкретно в данном случае можно обойтись без шорткатов и сделать всё правильно, то почему нет?justme Автор
17.10.2019 21:39Ну это мы уже переходим в типичный холивар не имеющий ни начала ни конца
1) смысл символа был придуман давно, с тех пор многое поменялось. к примеру возьмите символ перевода каретки (\r) и символ новой строки (\n). Второй изначально не переводил курсор в начало строки, а лишь сдвигал его на одну строку вниз. Но почему-то Unix решил что они сделают иначе и используют ТОЛЬКО \n (а первые Маки использовали ТОЛЬКО \r)
Еще можно вспомнить про символ вертикального таба… но тогда мы вообще надолго зароемся. Так что аргумент не в кассу, прогресс не стоит на месте
2) Про замены никто и не говорит. А про то что такое «изначально правильно» — это большой вопрос. Как правило это то о чем договорятся на проекте. И чаще всего это именно пробелы. Google Code Convension советует именно пробелы, между прочим. Неужели вы считаете что вы настолько умнее Google что можете смело называть их советы «грубой ошибкой»?
Разный размер табов может нарушать требования по максимальной длине строки, да и вообще делает это требование сложнореализуемым
3) А можно уточнить где в браузере настраивается размер таба? Я и правда не в курсе
4) Эм… если кусок кода не помещается в экран, то лучшим решением будет разбить строку или переписать, а не «временно настроить другой размер таба». Иначе это что ж получается, у вас там 2 символа, у вас не поместилось, вы настроили на 1… а ваш коллега, привыкший работать на 8, вообще не может нормально смотреть ваш код потому что в экран ничего не влазит? Вот тут как раз лучше чтоб у всех одинаково отображалось
5) В vim indent-ы оно и переходит по ним быстро и удаляет целиком. Думаю во многих IDE-шках это тоже настраивается легко. А align-ы парсит как один символ пробела, конечно же
Это я к чему: мой пост был о том, что вероятно мне (а может и другим пробело-любам) стоит задуматься о том что при использовании табов для indent-а а пробелов для align-а плюсов становится больше, чем минусов. Но уж точно не стоит заявлять что использовать пробелы это грубая ошибкаvitaliy2
17.10.2019 22:02-1Неужели вы считаете что вы настолько умнее Google что можете смело называть их советы «грубой ошибкой»?
Эти стандарты писал человек, который просто не знал о существовании tab indent space alignment и о своей ошибке.
Например, большинство глупее [здесь подставьте имя любого учёного, жившего в 19-20 веках]. Тем не менее он во многом ошибался. А ты не ошибаешься. Это же касается и современных людей — даже самые уважаемые люди планеты делают очень серьёзные ошибки в силу отсутствия знаний, неверных предсказаний и т.?д. Это не значит, что если ты не сделал эту ошибку, ты умнее его. Вообще это не так просто измерять ум, это сложная тема, и тут надо мерить что-то более конкретное, а не просто «ум», хотя к теме эту уже не относится.
Эм… если кусок кода не помещается в экран, то лучшим решением будет разбить строку или переписать
Вы не поняли, что я имел ввиду. Допустим, стандарт 98 символов. Но мне вдруг надо поработать на маленьком нетбуке с очень маленьким экраном. На всех устройствах влезает, и этот стандарт очень удобен, а вот тут не влезает. Чем менять стандарт, лучше изменить размер отступа.
Разный размер табов может нарушать требования по максимальной длине строки, да и вообще делает это требование сложнореализуемым
Обычно у человека, который использует более большие табы, размер экрана в реальности значительно больше по длине, поэтому проблемы с отображением — нечастая штука.
Во-вторых, если проблема всё-таки есть, тут как раз и выявляется преимущество табов — можно настроить именно для этого проекта такой размер, чтобы всё влезало.
В-третьих, касательно написания кода — тут стандарт должен говорить о максимальной длине при определённом размере отступа, допустим, равному по длине четырём пробелам. Причём если бы у нас были бы строгие пробелы, то вышло бы ещё хуже, т.?к. нельзя было бы настроить при достаточной длине монитора, а тут можно. Остаётся небольшая проблема с отмериванием лимита, но если ты подходишь к концу строки, ты можешь посчитать (или уже знать) количество отступов и высчитать лимит. Либо просто оставить небольшой запас.
А можно уточнить где в браузере настраивается размер таба? Я и правда не в курсе
Поставьте расширение Stylus или Stylish, и укажите в нём следующий код для всех сайтов:
body { -webkit-tab-size: 4 !important; -moz-tab-size: 4 !important; -o-tab-size: 4 !important; tab-size: 4 !important; }
К сожалению, GitHub зачем-то переопределяет стандартный размер таба, настроенный в браузере, поэтому нужно ещё добавить такой код для GitHub:
.tab-size { -webkit-tab-size: 4 !important; -moz-tab-size: 4 !important; -o-tab-size: 4 !important; tab-size: 4 !important; }
Для его добавления создайте новый стиль и укажите: «в домене: github.com».
Но уж точно не стоит заявлять что использовать пробелы это грубая ошибка
С Вашей логикой не стоит заявлять, и что использование табов вместо пробелов — это грубая ошибка. Ок, чтобы не продолжать спор, скажем тогда так: «и табы вместо пробелов, и пробелы вместо табов — это грубая ошибка с моей точки зрения».justme Автор
17.10.2019 22:16Эти стандарты писал человек, который просто не знал о существовании tab indent space alignment и о своей ошибке.
Вы серьезно верите, что:
а) Google Code Style Guides писал ОДИН человек (при чем на все языки) и после этого никто их не проверял? Ну вот серьезно, что ли?
б) И вы реально верите, что этот/эти люди не знали о том что можно отступы делать табами а выравнивать пробелами?
Допустим, стандарт 98 символов
А можно уточнить где вы такой стандарт видели? Есть классический — 80. Есть расширенный — 120. Про 98 не слышал
И что это за современный нетбук где по ширине не влазит 98 символов?
Строка может быть заполнена и не отступами, тогда изменение размера таба вам ничем не поможет
Обычно у человека, который использует более большие табы, размер экрана в реальности значительно больше по длине, поэтому проблемы с отображением — нечастая штука.
Это откуда такая интересная информация? Максимальная длина строки — это не редкое требование в проектах к code style. Как именно предлагаете его придерживаться с разной длиной таба?
если проблема всё-таки есть, тут как раз и выявляется преимущество табов — можно настроить именно для этого проекта такой размер, чтобы всё влезало.
А может лучше не допускать проблемы изначально, а не героически решать созданную самолично проблему «под каждый проект»?
А если работаешь сразу над двумя проектами, и в одном нужен отступ в 4 а в другом влазит только 2, каждый раз менять настройки IDE?
В-третьих, касательно написания кода — тут стандарт должен говорить о максимальной длине при определённом размере отступа, допустим, равному по длине четырём пробелам. Причём если бы у нас были бы строгие пробелы, то вышло бы ещё хуже, т.?к. нельзя было бы настроить при достаточной длине монитора, а тут можно. Остаётся небольшая проблема с отмериванием лимита, но если ты подходишь к концу строки, ты можешь посчитать (или уже знать) количество отступов и высчитать лимит. Либо просто оставить небольшой запас.
Я чего-то не понимаю или вы реально предлагаете СЧИТАТЬ для каждой строки сколько там осталось до лимита в «виртуальных» размерах таба? Т.е. если я поставил таб в 8 симовлов, а у меня строка вышла на 15 символов выше лимита, то я должен еще проверить что в моей строке содержалось не менее чем 4 (Math.ceil(15 / (8-4))) таба? Так что ли, или я что-то упустил?
Поставьте расширение Stylus или Stylish, и укажите в нём следующий код для всех сайтов:
Замечательно, еще один костыль чтоб табы отображались нормально ))) А на мобильном девайсе и в почте и в RSS ридерах мне тоже надо как-то умудриться поставить расширение?
С Вашей логикой не стоит заявлять, и что использование табов вместо пробелов — это грубая ошибка
Ну вообще-то да. Использование табов для alignment-а блоков кода высаковероятно приведет к проблемам, если размер табов в разных средах будет разным. Однако называть это «ГРУБОЙ ошибкой» я бы тоже не стал, несмотря на то что тут на лицо в основном минусы а не плюсы
А в том о чем пишете вы — это чистый холивар, тут и плюсов и минусов хватает с обеих сторон, потому говорить об ошибках вовсе не стоитvitaliy2
17.10.2019 22:38А можно уточнить где вы такой стандарт видели?
Вы — ещё один человек, который не понимает значение слова «допустим». Это число взято с потолка, в этом и смысл «допустим». Число используется для дальнейших рассуждений. При этом в каждой новой ситуации или каждой новой логической цепочке число уже может быть другим.
Строка может быть заполнена и не отступами, тогда изменение размера таба вам ничем не поможет
Я написал «влезал или почти влезал». Т.?е. я не имел ввиду, чтобы влезал во всех строках, но даже в части строк это уже иногда может сильно помочь.
Это откуда такая интересная информация?
Данная информация основана на статистике — у большинства мониторы формата 16:9 или порядка того. Данные мониторы настолько широкие, что может влезть даже 200 символов без учёта табов. Со стандартами 80 или 120 остаётся огромный запас.
Максимальная длина строки — это не редкое требование в проектах к code style. Как именно предлагаете его придерживаться с разной длиной таба?
Я же уже объяснил. С чтением проблем нет, с написанием придётся отмерять количество табов или оставлять небольшой запас от лимита.
+IDE же может автоматически отмерять за Вас.
А если работаешь сразу над двумя проектами, и в одном нужен отступ в 4 а в другом влазит только 2, каждый раз менять настройки IDE?
Как раз таки наоборот — у тебя будет тот размер, какой хочешь ты. Во всех проектах. Что очень круто. А так бы пришлось каждый раз переформатировать файл (пусть и автоматически), а потом возвращать обратно, что тупо и какой-то костыль :(
Я чего-то не понимаю или вы реально предлагаете СЧИТАТЬ для каждой строки сколько там осталось до лимита в «виртуальных» размерах таба? Т.???е. если я поставил таб в 8 симовлов, а у меня строка вышла на 15 символов выше лимита, то я должен еще проверить что в моей строке содержалось не менее чем 4 (Math.ceil(15 / (8-4))) таба? Так что ли, или я что-то упустил?
Да, я предлагаю считать, либо оставлять небольшой запас, чтобы не упираться в лимит.
Только подсчёт не такой тяжёлый. Если лимит 80 символов при табе в 4 символа, а у тебя таб 8 символов, то значит, если у тебя в текущей строке находится 5 табов, то лимит 100 символов (прибавляем 5 * 4).
Если у тебя 5 табов по 3 символа, то лимит 75 символов.
Если 5 табов по 2 символа, то 70 символов. Как видно, подсчёт очень простой.
+IDE же может автоматически уведомлять о выходе за лимит, тогда считать ничего не нужно.
+IDE же может писать текущую позицию при другом размере таба.
Замечательно, еще один костыль чтоб табы отображались нормально )))
Костыль? Это стандартное расширение для настройки отображения. Ну конечно по хорошему нужно добавить в about:config, Вы можете создать pull request самостоятельно (в Firefox). Это уже претензия к браузеру.
В этом и плюс, что можно настроить. А что делать с пробелами? Убиться(
тут и плюсов и минусов хватает с обеих сторон
Пока Вы привели единственный минус — необходимость подсчёта при использовании стандарта на лимит ширины строк. За что Вам спасибо.
Хотя этот подсчёт достаточно несложный, либо не требуется вообще, если у Вас не недоделанный IDE (что является недостатком уже самого конкретного IDE, а не стиля). Итого имеем один небольшой недостаток с одной стороны и кучу очень больших недостатков с другой. Поэтому я и называю это грубой ошибкой.justme Автор
17.10.2019 22:46Вы — ещё один человек, который не понимает значение слова «допустим»
Если многие не могут понять вас — возможно проблема не во многих)))
Но вообще — какой смысл брать цифры с потолка когда можно оперировать реальными данными? Мы же не сферических циплят в вакууме препарируем
16:9 или порядка того. Данные мониторы настолько широкие
Вы вот сейчас мне вообще мозг взрываете. При чем тут отношение сторон экрана и количество влезаемых в экран символов? Число символов будет зависеть от предоставленного размера в пикселях по ширине, от шрифта (и не только размера каждого символа но и отступов между символами). А шрифт будет выставляться в зависимости от предпочтений пользователя и от плотности пикселей на экране (точнее от физического размера)
Попрошу также не забывать что многие привыкли иметь в IDE колоночную структуру где слева — древо проекта и файлы, по центру — код, справа — документация или отладка или еще что-то. Так что размер экрана тут не так сильно играет роль
с написанием придётся отмерять количество табов или оставлять небольшой запас от лимита.
и вы не видите тут никакой проблемы? Ну ок
Да, я предлагаю считать, либо оставлять небольшой запас, чтобы не упираться в лимит.
После этого я предлагаю закрыть дискуссию, мне, если честно, даже сказать нечего на эти аргументыvitaliy2
17.10.2019 22:49и вы не видите тут никакой проблемы? Ну ок
Вижу, поэтому ниже и сказал, что вообще IDE же сам будет отмерять. Просто иногда туплю. В итоге проблемы нет (не считая, что я туплю XD).
Кто-то слил мне карму :( Хотя я привёл хорошее сравнение подчасти стиля.justme Автор
17.10.2019 22:57вы на большую часть моих вопросов выше так и не ответили. Мне и правда интересно было бы услышать ответы
что вообще IDE же сам будет отмерять
а можно пример IDE который подскажет вам длину строки при, скажем, табе в 4 если вы задали 8? Я просто не встречал такого
орошее сравнение подчасти стиля
ну, имхо, конечно, но это дикий костыль. и в большей части случаев он попросту не сработает (о чем я писал выше)vitaliy2
18.10.2019 02:27вы на большую часть моих вопросов выше так и не ответили. Мне и правда интересно было бы услышать ответы
Во-первых, Вы упомянули, что табы вместо пробелов — действительно ошибка, а пробелы вместо табов уже под вопросом.
Это не так. Табы вместо пробелов — намного меньшая ошибка. Так происходит, потому что чтобы не поехало выравнивание, ты просто можешь поставить такой же размер таба, как и автор. А можешь и не ставить, и смириться с поехавшим выравниванием. По крайней мере у тебя есть выбор.
С пробелами вместо табов всё хуже — выбора нет, и ты всегда обязан использовать такой же размер таба, как и автор. Единственный выход — автоматический преобразователь кода, который причём умеет всё возвращать обратно, чтобы не создавать конфликты в git и в целом. Но это больно запарно.
Далее по поводу неотвеченного:
смысл символа был придуман давно, с тех пор многое поменялось
Я судил по текущему смыслу. Конечно смысл любых вещей (например, слов в языке), если это НЕ что-то технически задокументированное (но не слово), это вещь холиварная.
Если я говорю о смысле, я говорю о смысле именно в моём понимании, либо же в общепринятом понимании. Других вариантов просто нет. Разве что использование авторитетных источников, которые опрашивают людей или собирают информацию о разных используемых смыслах и их частоте (например, словари). С помощью таких источников можно доказывать, что какое-то мнение или смысл является общепринятым, а не принадлежит одному человеку. Также их можно использовать для справки. Конечно это всё не может являться чем-то научно строгим, определённым на 100%.
Говоря о логичном применении таба в качестве отступа я в первую очередь выразил своё лично мнение. Оно основывается на том, что уже много лет символ и клавиша таба используются именно для этого, и даже когда кто-то использует пробелы вместо табов, он всё-равно нажимает клавишу таб.
Также эта клавиша используется для таблиц и похожих на них вещей (например, для перемещения фокуса на следующий элемент). Выравнивание таблицей не явлется, но может использоваться клавиша tab для вставки пробелов просто из-за удобства.
Как правило это то о чем договорятся на проекте.
Итак понятно, что юзать нужно то, что требует проект, но если сам проект при этом юзает плохой стиль, то это будет неправильно.
В vim indent-ы оно и переходит по ним быстро и удаляет целиком. Думаю во многих IDE-шках это тоже настраивается легко. А align-ы парсит как один символ пробела, конечно же
Я не стал отвечать, т.?к. итак понятно, что если парсит, то описанный мною недостаток серьёзно уменьшается.
Это я к чему: мой пост был о том, что вероятно мне (а может и другим пробело-любам) стоит задуматься о том что при использовании табов для indent-а а пробелов для align-а плюсов становится больше, чем минусов. Но уж точно не стоит заявлять что использовать пробелы это грубая ошибка
Не ответил, т.?к. возразить нечем.
Вы серьезно верите, что:
Я знаю кучу примеров, где люди просто не хотят ничего исправлять и делают так, как делали раньше.
а) Google Code Style Guides писал ОДИН человек (при чем на все языки) и после этого никто их не проверял? Ну вот серьезно, что ли?
б) И вы реально верите, что этот/эти люди не знали о том что можно отступы делать табами а выравнивать пробелами?
Например, разработчики под Linux ведь не глупые, но большинство пока ещё не использует стандарт XDG. Хотя за такое хочется руки поотрывать.
При этом пройдёт время, и когда-то настанет момент, когда таких программ не останется. Просто все изменения не происходят сразу, люди любят делать по инерции.
Вы же не подошли к этим разработчикам, написавшим Google Code Style Guides, и не спросили: «А почему Вы не рекомендуете использовать Tab indent space alignment? Значит ли это, что его использовать не нужно?". Тогда бы опытный разработчик (или несколько) могли бы взвесить все плюсы и минусы и дать профессиональный ответ.
А в самом гайде это сейчас даже не упомянуто. Там же не написано, не используйте этот стиль. Там вообще ничего про него не написано. Как будто разработчики ничего не слышали про него.
При этом в реальности часть может слышала, но не хочет ничего менять, ведь на то, чтобы внести изменения, нужно потратить силы, а также посоветоваться с другими разработчиками. Как видно, все изменения делаются медленно.
Как итог, если про что-то ничего не написано в профессиональном источнике, тебе придётся самому взвешивать решение, либо использовать другие источники. В Google Code Style Guides ничего не написано.
+К этому я сам являюсь профессиональным разработчиком, и могу высказать своё профессиональное мнение.
А может лучше не допускать проблемы изначально, а не героически решать созданную самолично проблему «под каждый проект»?
Я изначально Вам ответил, что можно просто поставить во всех проектах один размер, и только сейчас понял, что имеется ввиду, что нужно уменьшить размер для определённого проекта, если код начал не влезать.
А если работаешь сразу над двумя проектами, и в одном нужен отступ в 4 а в другом влазит только 2, каждый раз менять настройки IDE?
Во-первых, по моему мнение, это придётся делать крайне редко, не считая маленьких экранов (например, на нетбуке).
Во-вторых, разумеется, если IDE вдруг не позволяет выбрать разные настройки для разных проектов, то стоит сменить IDE, т.?к. это уже критический недостаток (отсутствие самой базовой функциональности). Это было бы достаточно глупо — IDE реализует очень много фич очень большой сложности, но не реализует такие базовые вещи. В любом случае, это всё уже является недостатком IDE, и к стилям отношения не имеет.
это «ГРУБОЙ ошибкой» я бы тоже не стал, несмотря на то что тут на лицо в основном минусы а не плюсы
Я уже ответил, но на всякий раз отвечу снова:
Да, правильно было сказать не «является грубой ошибкой», а «является грубой ошибкой с моей точки зрения». Здесь Вы правы — я составил неверную формулировку.
Вы вот сейчас мне вообще мозг взрываете. При чем тут отношение сторон экрана и количество влезаемых в экран символов? Число символов будет зависеть от предоставленного размера в пикселях по ширине, от шрифта (и не только размера каждого символа но и отступов между символами). А шрифт будет выставляться в зависимости от предпочтений пользователя и от плотности пикселей на экране (точнее от физического размера)
Я это не учёл. Но думаю, даже если поставить очень большой шрифт и панели, чаще всё-равно всё влезет.
Попрошу также не забывать что многие привыкли иметь в IDE колоночную структуру где слева — древо проекта и файлы, по центру — код, справа — документация или отладка или еще что-то. Так что размер экрана тут не так сильно играет роль
При этом я не сказал, что это 100%. Если не влезло, можно: 1) Уменьшить размер шрифта в этом проекте. Неактуально, если работаешь с нетбука. 2) Изменить размер отступа именно в этом проекте.
Как итог, проблемы нет.
а можно пример IDE
Я не разбираюсь в IDE, поэтому нет. Если в каком-то IDE нет такой базовой функциональности, это уже проблема IDE. Нужно уведомить разработчиков об этой проблеме.
Конечно всякие баги и проблемы в IDE и редакторах влияют и на сам стиль (косвенно), но всё-таки это всё слишком базовая функциональность, чтобы IDE мог так просто на неё забить. Иначе какой смысл вообще реализовывать дофига сложные вещи в IDE, но забить на базовые простые вещи, реализация которых очень проста?
«Хорошее сравнение подчасти стиля» — случаев он попросту не сработает (о чем я писал выше)
Вы не поняли, что я имел ввиду. Я привёл хорошее описание, чем табы на месте табов, лучше, чем пробелы вместо табов. Почти полное сравнение, не считая пункта, который сказали Вы. Что является ценным материалом. А мне заминусили карму :(
Подчасти — имеется ввиду, что я не весь стиль описал, а именно табы на месте табов. Вторая часть стиля — пробелы на месте пробелов. А также нужно про сам стиль рассказать (немало). Если всё это совместить, выйдет хорошая статья.
Вам спасибо всё-равно за недостаток + за указание на ошибку. Я не буду в будущем допускать ошибок формулировок. Говорить чётко утвердительно на утверждение без АИ — неправильно, это фактическая ошибка. Но если добавить «по моему мнению», то уже фактической ошибки нет.justme Автор
18.10.2019 02:45если добавить «по моему мнению», то уже фактической ошибки нет.
да, тогда накал общения был бы куда меньший :)
Во-вторых, разумеется, если IDE вдруг не позволяет выбрать разные настройки для разных проектов, то стоит сменить IDE
если честно во всех IDE которые я знаю подобные настройки ставятся если не на всю IDE, то в лучшем случае на отдельные языки, но точно не на разные проекты
Я могу ошибаться, но если таких настроек и правда нет — вероятнее всего они попросту не востребованы. Ровно как и настройка величины таба в браузерах.
Не пытаюсь переубедить вас, т.к. вообще-то статья была именно о том что табы, вероятно, лучше. Но просто хочу попробовать зародить сомнение в вас насчет того, что если нигде никто не вводил эти настройки — возможно оно никому и не нужно, и это попросту необычное решение проблемы которой у большинства людей вовсе и нет?
Я не разбираюсь в IDE
+К этому я сам являюсь профессиональным разработчиком
Не с целью что-то доказать а просто праздный интерес: а на чем вы пишите, под какой средой разработки и как давно? Просто необычно чтоб разработчик в IDE не разбирался. Я сам всю жизнь предпочитаю vim-редактор по возможности вместо IDE, но все равно кое-как да разбираюсь в IDE
В Google Code Style Guides ничего не написано.
Не сказано, т.к. Code Style обычно содержит список указаний а не детальных пояснений почему и зачем. В том же Go написано что нужно использовать табы, но причин не указано. Есть небольшие отрывки в статьях, интервью и, кажется, FAQ, но не в code stylevitaliy2
18.10.2019 09:27Просто необычно чтоб разработчик в IDE не разбирался.
Так и думал, что к этому придерутся :). Но я не думаю, что профессиональный разработчик должен разбираться ну прямо вообще во всём, во всём невозможно. Хотя чем профессиональнее, тем больше должен знать в разных областях.
Я разберусь с IDE обязательно, но потом. Но для оценки табов профессионализма в тех областях, в которых он у меня есть, мне достаточно. По крайней мере если не брать косвенных недостатков разных стилей из-за несовершенности определённых IDE, которые кто-то может любить.
Не сказано, т.???к. Code Style обычно содержит список указаний а не детальных пояснений почему и зачем.
И как итог, раз пояснений нет, такой Code Style устареет уже через пол года, т.?к. нет возможности определить, его авторы специально убрали из него что-то или же просто ещё не добавили по мере меняющейся обстановке в мире.
В данном случае я уверен на 99.99%, что второе.
И ведь говорить же про этот стиль стали не так давно. А даже если часть разработчиков слышала, все изменения в такие штуки могут быть очень неподвижными по причинам, которые я уже назвал до этого.
И важно:
Вот Вы сказали этот Code Style писал не один человек, а несколько. Так это ещё хуже. Значит все изменения нужно согласовывать с другими людьми, и это может быть очень запарно. Получается, нужно каждого убедить в правильности своего мнения. И каким бы правильным оно не было, это просто запарно. Проще забить.
Везде, где в процессе участвует более одного человека, работа иногда может начать делаться значительно медленнее.justme Автор
18.10.2019 09:38Я разберусь с IDE обязательно, но потом
Конечно во всем разбираться не может. Но и бросать громкие заявления в областях в которых не разбирается — вроде тоже не очень хороший тон.
Кстати о том под чем пишете и как давно так и не ответили :)
И как итог, раз пояснений нет, такой Code Style устареет уже через пол года
Вы вообще много видели в своей жизни Code Style-ов? В скольких из них было пояснена причина выбора табов или пробелов?
Google Code Style уже примерно лет 10, так что проверку временем он уже прошел.
Получается, нужно каждого убедить в правильности своего мнения. И каким бы правильным оно не было, это просто запарно. Проще забить.
Ну вы сами себе противоречите. Сначала говорите что программист Google просто допустил ошибку и не знает о том что можно использовать табы. Теперь выясняется что это не ошибка а «нужно каждого убедить»… или вы думаете что там весь отдел ошибается? Вообще весь мир ошибается и не знает про табы?)))
vitaliy2
18.10.2019 10:13бросать громкие заявления в областях в которых не разбирается — вроде тоже не очень хороший тон
Это да (я, естественно, так не делал, не считая возможных косвенных недостатков, про что я честно сказал, что не разбираюсь).
Ну вы сами себе противоречите. Сначала говорите что программист Google просто допустил ошибку и не знает о том что можно использовать табы. Теперь выясняется что это не ошибка а «нужно каждого убедить»…
Ага, я неясно выразился. На самом деле я имел ввиду, что я не знаю точно, какой вариант истинный, и привёл разные гипотезы, почему в итоге оно так, как оно есть. Какая из них верная, я не знаю, а может и каждая влияет понемногу.
или вы думаете что там весь отдел ошибается? Вообще весь мир ошибается и не знает про табы?)))
Ну давайте будем честными: вот Вы когда узнали про стиль Tab indent space alignment? Явно же не в детстве. Лично я узнал его только года 2–3 назад, хотя программирую уже 13 лет.
Логично предположить, что и остальные люди могут пока не знать. Я не слышал, чтобы его упоминали по 100 раз на дню.
Аналогично и со стандартом XDG — кажется, что только дурак может его игнорировать или изверг, любящий поиздеваться над людьми, но тем не менее пока ещё большинство игнорирует :( Это не значит, что они глупые или садисты, причины в другом.
Даже вон Mozilla упиралась от использования webp. Да, понятно, что плодить зоопарк не нужно, но ведь момент настал, с выпуска jpeg прошло 25 лет (на 2016 год), а webp сжимает до 2 раз лучше (верхняя граница) и сам по себе является очень неплохим форматом и, можно сказать, спасенье для веба. Так почему бы его не поддержать? Но по политическим причинам нет (хотя в 2019 таки решились, несмотря на то, что уже avif на носу).
justme Автор
18.10.2019 10:05Ну все же не совсем бесполезное. То что люди в редакторах настраивают такое поведение — уже о многом говорит. Если редактор имеет это как настройку по-умолчанию — тоже с высокой вероятностью говорит о том что таково предпочтение юзеров. Все таки современные продукты (в том числе IDE) чаще всего строятся отталкиваясь от статистики пользования
phantom-code
15.10.2019 10:51Всегда предпочитал табы, правда основным для меня моментом была возможность быстрого перемещения курсора «сквозь» отступы. Если бы текстовый редактор позволял по нажатию стрелки прыгать сразу через все пробелы в отступе, я бы не особо интересовался, табы там на самом деле или пробелы.
Akina
15.10.2019 11:19Если вместе с нажатием стрелки притопить Ctrl — то как раз и получишь прыжок «сквозь отступы». Причём в этом случае поведение курсора не зависит от того, таб или пробел.
phantom-code
15.10.2019 11:29Только придется использовать клавишу-модификатор, так что проще использовать табы.
vitaliy2
16.10.2019 13:27Настройте себе RAlt + ESDF (аналог ^
) и A G (аналог Ctrl + < >). Только клаву выберите такую, чтобы RAlt был под M.
Заодно на RAlt можно повесить Compose Key (при одиночном нажатии).
Может, я когда-нибудь выложу свой скрипт (под Windows).phantom-code
16.10.2019 13:36Я уже делал что-то похожее несколько лет назад, только в качестве клавиши модификатора использовал пробел, т.к. его гораздо проще удерживать любой рукой. Идея была в том, что пробел генерирует код клавиши «пробел» только при отпускании, если не было нажато запрограммированной комбинации клавиш, где он участвует как модификатор. В принципе идея работала, но для меня это оказалось все равно неудобно.
PeterK
15.10.2019 20:22Я тут читаю про NoSQL, так там прямо говорят «denormalize data», а тут «исходники занимают меньше места». Мне казалось, что со времен, когда была создана Y2K problem прошло уж очень много времени.
justme Автор
15.10.2019 20:32А при чем тут Y2K Problem? Если компы могут оперировать 64-битными переменными, могут иметь более 4Гб оперативы и очень быстрые процы, то на производительность можно положить болт?
На клиентской части на оптимизацию скорости и потребляемых ресурсов большинство рядовых программистов уже забило. Но вот на серверах это расточительно забивать на такие вещи, т.к. там где можно было бы обойтись несколькими сотнями долларов в месяц на сервера приходится закупать в десятки раз больше мощностей и серверов, и ценник ростет соответственно
Конечно это не имеет никакой связи с размером исходников, но денормализация баз данных — штука необходимая не только в NoSQL но и в SQL
Вообще идеальные формы баз данных, по моему опыту, хороши только в теории а не в продакшене. В теории они оптимизируют хранимое место… только вот время выборки, время блокировки таблиц и загруженность CPU и памяти — растет
vintage
16.10.2019 19:19Я тут читаю про NoSQL, так там прямо говорят «denormalize data»
Вредные советы? :-)
justme Автор
16.10.2019 19:21А чего вредные то? Если денормализация делается грамотно — то она идет только на пользу а не во вред. Нормальные формы баз данных максимально полезны только в академических трудах. На практике кроме размера хранения и дублирования данных есть еще блокировка таблиц, время выборки, использованая оперативка и CPU и т.д.
И вот в таких случаях денормализация может быть очень полезным и эффективным методом оптимизации
Надостаточно избежать дублирования данных чтоб сказать «у меня тут все здорово»
Недостаточно применить наобум денормализацию чтоб сказать «я все сделал в соответствии с самыми современными советами по проектированию баз данных»
Все нужно использовать с умом и четким пониманием целей и компромисовvintage
16.10.2019 20:05Недостаточно применить наобум денормализацию
Вот именно это там и написано:
denormalize data
mayorovp
17.10.2019 09:05Ну, блокировок таблиц после денормализации становится только больше.
justme Автор
17.10.2019 14:09С каких делов?
До денормализации чтобы получить данные по связанным сущностям вам прийдется сделать JOIN, который временно заблокирует сразу несколько таблиц (ну или их участков, зависит от базы данных). После грамотной денормализации вероятнее всего JOIN-ов должно стать меньше, а блокировка будет только одной таблицы
Больше блокировок будет при записи, однако тут уже вопрос того как используется база данных. Если у вас очень много записей и мало выборок — тогда может и денормализация не нужнаvintage
17.10.2019 17:29Расскажите по подробнее про таблицы и их джойны в NoSQL.
justme Автор
17.10.2019 17:51Ну да, в NoSQL не таблицы — а коллекции. Соответственно блокироваться будут не таблицы и не записи, а документы
JOIN-ы в некоторых реализациях NoSQL, насколько я помню, имеются. В противном случае делаются через код, что не меняет факта преумножения блокированныхзаписейдокументов
Но NoSQL вообще обычно лучше не юзать если у вас преимущественно чтение а не запись. А при записи денормализация чаще идет в минус, чем в плюс. Сильно тонкие уже случаи должны быть
mayorovp
18.10.2019 08:33А если операций записи мало — то и блокировки при записи тоже ни на что не повлияют, ведь они будут редкие.
Блокировки же, накладываемые при чтении, не являются эксклюзивными, и другим операция чтения никак не мешают. Это если они вообще накладываются.
justme Автор
18.10.2019 10:02Про блокировки при чтении — вы полностью правы
Однако я бы не сказал что при записи блокировки ни на что не повлияют. Блокировки влияющие на производительность происходят при частом смешанном обращении к одним и тем же таблицам (или участка таблиц, если шардинг). Т.е. если идет запись в таблицу и параллельно еще 7 потоков ждут эту таблицу на чтение — то им всем надо ждать пока произойдет запись. Если у вас Join запрос — то вероятность что в этот момент в одну из этих таблиц идет запись преумножается, ровно как и вероятность ожидания блокировки
ilya-ivanov
17.10.2019 17:10Надо ввести в отношении табов и пробелов закон Don't ask, don't tell. Пока IDE справляется, нормальному человеку лучше не знать, что 50% окружающих — извращенцы :)
(Спойлер: изюм тезиса в том, что он работает в обе стороны).justme Автор
17.10.2019 17:13IDE не будет хорошо справляться если файл будет содержать мешанину из пробелов и табов, а это будет происходить если один файл будут править извращенцы с разных сторон
Кроме того прийдется дополнительно настраивать git чтобы изменение IDE-шкой пробелов на табы или наоборот оно не считало за diff
А еще множество проблем связанных с align-ом (особенно табами)
Короче на моей практике на проектах просто изначально все договаривались об одних настройках
MTonly
Да, всё правильно: табуляция — для отступов; пробелы — для выравнивания.
petuhov_k
Ну что вы, тогда же не будет холивара.
justme Автор
Изначально статья была не для холивара, а именно для закрытия оного.
Но, видимо, я недооценил многих вещей. На то они и холивары, чтоб никогда не заканчиваться. За то и закидали пост минусами :(
Сам виноват, что уж