![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Религиозное - о пробелах и табуляциях в текстах программ
Вынесено из комментов.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
no subject
no subject
no subject
no subject
разве что способы реализации )
set expandtab
set tabstop=4
no subject
no subject
1. Я знаю чем пользуются довольно многие из людей, которые полезут в мой код - 90% - либо vim, либо emacs.
2. Я точно знаю у значительного числа из этих людей табуляция настроена так, как им удобно.
Мнение о моем коде (имеется в виду opensource) тех людей, у которых редактор не настроен, меня, как правило, не интересует. Поскольку они не обладают первой из трех добродетелей программиста по Ларри Уоллу.
3. Утилитам, которые обрабатывают код, как правило пробелы/табуляции пофигу. whitespace оно и есть whitespace. (to
4. Те кто пишет код такой вложенности что при разумном размере табуляции (2-4 символа) оно не влазит на терминал 80x25 независимо от длины идентификаторов - неправы.
Ну вот, holy war...
Я работаю над proprietary корпоративными информационными системами.
Вы работаете над проектами open source? Ядро Linux?
Вы ограничены стандартами де-факто - vim и emacs. Я ограничен гораздо бОльшим разнообразием тулзов под Windows (хоть и за счёт несколько меньшего качества или проприетарности; будем смотреть фактам в лицо), помноженным на вкусы своих сотрудников; и стандартным софтом своей или клиентской платформы - Windows, AIX, whatever.
1. Я НЕ знаю, чем пользуются те, кто полезет в мой код или код моих коллег. Это могут быть любой из нас (в т.ч. через годы), начальство, QA. Эта посылка к нам не относится.
2. Значительное (вернее, единственно значащее) число людей в нашем случае - это наше подразделение. И меня очень интересует, чтобы ВСЕ из них могли удобно читать и писать код.
3. Утилитам пофигу, а вот тем, кто смотрит на их вывод - нет. Потому что вывод совсем не обязательно идёт в vim или emacs. См. ниже.
4. "Так-то воно так, та трішечки не так". Во-первых, программисты у нас бывают разные. Наш стандарт позволяет вложенность конструкций до 4 уровня. Плюс namespace - сейчас мы работаем на До-Диез. 5 уровней * 8 = 40, полэкрана гуляет. Плюс - идентификаторы длинные... Извините, не наш выбор. Наш выбор - два пробела.
Насчёт 2-4 - позвольте не согласиться: я НЕ делаю предположения, что все перенастраивают все тулзы. Цитирую себя:
клиенты email, Notepad, браузер, LPT, в единственном телнетном редакторе на клиентском сервере - vi (не путать с vim), на терминальном сервере интеграционной тимы, где нужно работать только под одним специальным юзером.
Дефлотная ширина таба - 8.
Ваши предположения, наверное, верны для вашей области, но не для моей.
Писать правильный софт под правильные системы в правильном коллективе за правильные деньги - увы, сейчас у меня такой опции нет. Если я ошибаюсь - мои координаты в юзеринфо.
Re: Ну вот, holy war...
В корпоративной среде - все сильно проще. Берем и устанавливаем корпоративный стандарт. Проконсультировавшись, естественно, у наиболее опытных и уважаемых сотрудников. А всех остальных просто силой заставляем этот стандарт использовать.
В итоге мы с коллегами посовещались и решили что у нас в конторе стандарт - табуляция.
Разговор о том, как правильнее писать имеет смысл только в контексте неопределенной аудитории, то есть в случае OpenSource.
Ограничение набора инструментов - в первую очередь самоограничение. В мире OpenSource тоже есть куча всяких IDE-образных поделок и code-browser-ов. Посмотрели, попробовали, выругались и выбросили. Понятно, что проприетарную софтину, за которую деньги плачены - выкидывать жальче. Но ведь обычно есть trial-версии.
Что такое "клиент email" я не совсем понимаю. Бывает e-mail внутри Emacs, бывают E-Mail клиенты, которые в качестве редактора вызывают vim, всё остальное просто неудобно в использовании.
Но самое главное мое положение заключалось в том, что люди делятся на две непересекающиеся категории - те, которые в ненастроенном софте не работают, и те, мнение которых о коде неинтересно, потому что ничего умного всё равно не скажут.
Начальство того уровня, которое заглядывает в код почему-то у меня однозначно попадает в первую категорию. Во вторую могут, конечно, попадать сотрудники сертифицирующих органов, с мнением которых приходится считаться, даже если оно и неинтересное. Но они обычно код смотрят крайне бегло.
И еще - существуют автоматизированные форматтеры исходного кода, GNU indent, к примеру, которые прекрасно решают эту проблему, позволяя каждому работающему с кодом видеть его как ему удобно, а в репозиторий складывать как того требует корпоративный стандарт.
Re: Ну вот, holy war...
1. Что такое "клиент email" я не совсем понимаю. Бывает e-mail внутри Emacs, бывают E-Mail клиенты, которые в качестве редактора вызывают vim, всё остальное просто неудобно в использовании.
Это а) вопрос вкуса б) требует настройки размера таба в приложении, не предназначенном для просмотра кода.
2. "Те, которые в ненастроенном софте не работают, и те, мнение которых о коде неинтересно, потому что ничего умного всё равно не скажут".
Я по этой классификации отношусь ко второй. Я периодически работаю в ненастроенном софте по различным субъективным и объективным причинам, а также смотрю код в софте без возможности настроить размер таба.
Разговор о том, как правильнее писать имеет смысл только в контексте неопределенной аудитории, то есть в случае OpenSource.
Либо на случай помянутого совещания. Которые всем нам ещё предстоят в грядущих проектах.
существуют автоматизированные форматтеры исходного кода, GNU indent, к примеру, которые прекрасно решают эту проблему, позволяя каждому работающему с кодом видеть его как ему удобно, а в репозиторий складывать как того требует корпоративный стандарт.
"Не следует умножать сущности без необходимости." ©
Re: Ну вот, holy war...
Есть такой термин - MUA. Гугль расскажет.
Я вот как-то плохо представляю, как люди, не связанные с программированием (к примеру, product specialists) могут использовать mutt/pine/gnus etc.
Потому что для удобной работы их нужно очень долго настраивать под себя. Причём это итеративный процесс, в духе "попользовал пару дней - показалось странным нечто - перенастроил", то есть спихнуть эту работу на специального человека не получится.
Добавив сюда тот факт, что ни один из вышеназванных не поддерживает out-of-box генерацию HTML, в котором обычно идёт 90% корпоративной переписки (спорить по поводу того, что HTML в письмах нужен, совсем не хочется - это и так очевидно), а также отсутствие мало-мальского юзабилити - и оказывается, что пользовать их неэффективно не только в плане своего времени, но и в плане времени корреспондентов (меня вот просто бесит, когда очередной отвечающий отвечает на HTML-письмо в plain text, теряя все выделения цветом фрагментов кода, выделения жирным ключевых фраз etc. - ему плевать не только на своё, но и на моё время)
no subject
С процитированной фразой вообще спорить бессмысленно. Потому что она как есть спорит о вкусах, а следовательно, ошибочна.
no subject
no subject
Re: Reply to your comment...
браузере настраивается размер таба.
Re: Reply to your comment...
Re: Reply to your comment...
мало того, каждый, кто использует свой размер таба, тоже настраивает.
А теперь вопрос - зачем? ;)
Re: Reply to your comment...
Зачем? А чтобы работать было удобнее. Как правило, с помощью небольшого числа хорошо знакомых и настроенных инструментов можно добиться куда большей эффективности, чем с помощью большого числа инструментов, которыми сам не помнишь как пользоваться.
И всегда, когда встает новая задача, прежде чем искать новое средство её решения - думаю, а нет ли средства её решить при помощи комбинации уже освоенных инструментов.
Re: Reply to your comment...
Проблема табов даже не в том, что это whitespace-символы, визуально не
отличимые от пробелов, но в том, что таб - это понятие в прямом смысле
растяжимое. В результате получается разброд и шатание: все инструменты
нужно перестраивать для каждого проекта.
ps: кстати, браузеры уже научились показывать в виде N+1
пробельного символа, а не N? А то те же diff'ы в них ужасно смотрятся.
no subject
no subject
Символ табуляции — это всего лишь способ сэкономить на пробелах, а сейчас эта экономия уже не нужна. Слава богу, мы уже не ограничены цифрами 640, 80x25, 8.3, 33600 и т.п.
no subject
Следует читать как
"Использование символа табуляции для отступов в коде — это всего лишь способ сэкономить на пробелах"