![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenВынесено из комментов.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
Tags:
Ну вот, holy war...
10/1/06 04:15 (UTC)Я работаю над 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...
10/1/06 04:57 (UTC)В корпоративной среде - все сильно проще. Берем и устанавливаем корпоративный стандарт. Проконсультировавшись, естественно, у наиболее опытных и уважаемых сотрудников. А всех остальных просто силой заставляем этот стандарт использовать.
В итоге мы с коллегами посовещались и решили что у нас в конторе стандарт - табуляция.
Разговор о том, как правильнее писать имеет смысл только в контексте неопределенной аудитории, то есть в случае OpenSource.
Ограничение набора инструментов - в первую очередь самоограничение. В мире OpenSource тоже есть куча всяких IDE-образных поделок и code-browser-ов. Посмотрели, попробовали, выругались и выбросили. Понятно, что проприетарную софтину, за которую деньги плачены - выкидывать жальче. Но ведь обычно есть trial-версии.
Что такое "клиент email" я не совсем понимаю. Бывает e-mail внутри Emacs, бывают E-Mail клиенты, которые в качестве редактора вызывают vim, всё остальное просто неудобно в использовании.
Но самое главное мое положение заключалось в том, что люди делятся на две непересекающиеся категории - те, которые в ненастроенном софте не работают, и те, мнение которых о коде неинтересно, потому что ничего умного всё равно не скажут.
Начальство того уровня, которое заглядывает в код почему-то у меня однозначно попадает в первую категорию. Во вторую могут, конечно, попадать сотрудники сертифицирующих органов, с мнением которых приходится считаться, даже если оно и неинтересное. Но они обычно код смотрят крайне бегло.
И еще - существуют автоматизированные форматтеры исходного кода, GNU indent, к примеру, которые прекрасно решают эту проблему, позволяя каждому работающему с кодом видеть его как ему удобно, а в репозиторий складывать как того требует корпоративный стандарт.
Re: Ну вот, holy war...
11/1/06 01:13 (UTC)1. Что такое "клиент email" я не совсем понимаю. Бывает e-mail внутри Emacs, бывают E-Mail клиенты, которые в качестве редактора вызывают vim, всё остальное просто неудобно в использовании.
Это а) вопрос вкуса б) требует настройки размера таба в приложении, не предназначенном для просмотра кода.
2. "Те, которые в ненастроенном софте не работают, и те, мнение которых о коде неинтересно, потому что ничего умного всё равно не скажут".
Я по этой классификации отношусь ко второй. Я периодически работаю в ненастроенном софте по различным субъективным и объективным причинам, а также смотрю код в софте без возможности настроить размер таба.
Разговор о том, как правильнее писать имеет смысл только в контексте неопределенной аудитории, то есть в случае OpenSource.
Либо на случай помянутого совещания. Которые всем нам ещё предстоят в грядущих проектах.
существуют автоматизированные форматтеры исходного кода, GNU indent, к примеру, которые прекрасно решают эту проблему, позволяя каждому работающему с кодом видеть его как ему удобно, а в репозиторий складывать как того требует корпоративный стандарт.
"Не следует умножать сущности без необходимости." ©
Re: Ну вот, holy war...
22/1/06 08:51 (UTC)Есть такой термин - MUA. Гугль расскажет.
Я вот как-то плохо представляю, как люди, не связанные с программированием (к примеру, product specialists) могут использовать mutt/pine/gnus etc.
Потому что для удобной работы их нужно очень долго настраивать под себя. Причём это итеративный процесс, в духе "попользовал пару дней - показалось странным нечто - перенастроил", то есть спихнуть эту работу на специального человека не получится.
Добавив сюда тот факт, что ни один из вышеназванных не поддерживает out-of-box генерацию HTML, в котором обычно идёт 90% корпоративной переписки (спорить по поводу того, что HTML в письмах нужен, совсем не хочется - это и так очевидно), а также отсутствие мало-мальского юзабилити - и оказывается, что пользовать их неэффективно не только в плане своего времени, но и в плане времени корреспондентов (меня вот просто бесит, когда очередной отвечающий отвечает на HTML-письмо в plain text, теряя все выделения цветом фрагментов кода, выделения жирным ключевых фраз etc. - ему плевать не только на своё, но и на моё время)
(no subject)
22/1/06 10:45 (UTC)С процитированной фразой вообще спорить бессмысленно. Потому что она как есть спорит о вкусах, а следовательно, ошибочна.