Вынесено из комментов.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
Я принципиально использую пробелы, потому что:
1. Читатель НЕ настраивает софт, которым читает код. Поэтому код должен выглядеть единообразно в любой смотрелке.
2. Слова о том, что кто-то что-то "может настроить как ему нравится" - обычно buzz. Потому что а) история не знает сослагательного наклонения, б) большинство ничего не делает по этому поводу.
3. Код читают (и ещё всячески обрабатывают) в разных программах, в т.ч. таких, где нельзя настроить размер табуляции.
4. Табуляция, может, и была придумана для отступов в программах, но в те времена, когда имена переменных были много короче 8 символов. А значит, табами можно было форматировать текст в красивые колонки и он не вылезал за правый край терминала. Те времена давно прошли.
Tags:
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)С процитированной фразой вообще спорить бессмысленно. Потому что она как есть спорит о вкусах, а следовательно, ошибочна.