Comments 161
Интересно. Сделали бы ещё для C и C++.
Угу, по Python-статистике сразу видно: люди делятся на тех, кто читал PEP8 и остальных :)
Может пора закончить часть этих священных войн и написать программу/модуль/плагин для автоматического изменения при открытие и закрытие файлов (запоминая изначальное положение)?
Это же куда проще, чем написать проект для сбора статистики с ГитХаба.
Это же куда проще, чем написать проект для сбора статистики с ГитХаба.
UFO just landed and posted this here
Но не всегда один проект разрабатывается одной командой.
Часто люди работают с чужими проектами, например Open Source. И в данном случае не хочется отходить от привычек.
Ну в общем я понял Вас: даешь больше холивара!
Часто люди работают с чужими проектами, например Open Source. И в данном случае не хочется отходить от привычек.
Ну в общем я понял Вас: даешь больше холивара!
UFO just landed and posted this here
Ну чтобы прийти к единому стилю — необходимо определиться устроить холивар в команде :D
UFO just landed and posted this here
Даже если все остальные не будут с ним согласны (в стилистике форматирования)?
ИМХО: это плохой ведущий разработчик, который не учитывает мнения большинства.
Ну даже если и так, то разве плохо иметь «универсальный преобразователь»?
Ниже уже развели очередной холивар. И это про табы/пробелы, для которых имеются встроенные во многие редакторы «преобразователи». Однако, с холиварами жить веселее, они же занимают кучу свободного времени. А если чуть-чуть потратить свободного времени и написать инструмент, то некуда будет девать позже свободное время.
ЗЫ Я бы написал, но я дизайнер и знаю только js и php — на них не напишешь.
ИМХО: это плохой ведущий разработчик, который не учитывает мнения большинства.
Ну даже если и так, то разве плохо иметь «универсальный преобразователь»?
Ниже уже развели очередной холивар. И это про табы/пробелы, для которых имеются встроенные во многие редакторы «преобразователи». Однако, с холиварами жить веселее, они же занимают кучу свободного времени. А если чуть-чуть потратить свободного времени и написать инструмент, то некуда будет девать позже свободное время.
ЗЫ Я бы написал, но я дизайнер и знаю только js и php — на них не напишешь.
UFO just landed and posted this here
надо все обсудить
Ниже в комментариях «обсуждают», хотя решение за каждым лично и оппоненты нет права на финальное решение для оппонента :D
Если бы такой метод прозрачно работал, им бы пользовались.
Ну конечно. Статистику собирать есть инструмент, а преобразовать пробелы в табы и наоборот (и прочее само собой) — нельзя? Не вижу проблем.
Эти инструменты превосходно подошли бы для подобной задачи, если бы она решалась.
Хм, на PHP и JS написать модуль/плагин (что предпочтительнее) для программы?
UFO just landed and posted this here
Поэтому есть человек, более опытный чем остальные, которому и принадлежит решающий выбор.
Но при этом мы не беспокоимся о дискомфорте работников.
Потеряются выравнвания (хотя с табами их использовать и не получится).
Потеряется пользовательское форматирование.
Появятся проблемы с длиной строк (с табами они всегда есть).
Хм. Не вижу тут проблем.
Алгоритм:
Вбиваются в настройки плагина предпочтения x пробелов или табы
Анализируется файл при открытие на наличие вариантов пробел/таб. Эти данные записываются во временную память (например tmp файл).
Форматируется согласно настройкам пользователя.
Закрываем/сохраняем файл — файл пишется согласно изначальным настройкам.
Потеряется история git.
Равно также, как и без оных (выше описанных) манипуляций.
Ради глупой нехотелки следовать стайлгайдам?
Сталгайды пишут боги? Нет. Поэтому кто как привык — сколько людей, столько и стайлгайдов.
И у меня чувство, что мне где-то наврали
считаю, что нет всеобщего единого стиля, которого все должны придерживаться.
Так же, напомню, что многие IDE умеют делать форматирование кода, только проблемы:
— делает как нравится разработчикам IDE
— нельзя восстановить форматирование как было.
Т.е. попытки уже были и есть. Надо просто усовершенствовать.
UFO just landed and posted this here
Код пишет человек. Он мог выровлять массив по разделителю, а мог не выровнять — такие вещи стайлгайдами не охватываются.
Вы предлагаете портить историю, делая реформат?
Да много чего не охватывается. Я про всё и не говорю. Можно начать с чего-то, а дальше уже наращивать. Статистика из статьи тоже всё не охватывает.
Ну а насчет портить — так не хочешь — не пользуйся, ни кто же не заставляет.
Как раз портится история, когда проект передается новым, или просто приходят новые и творят своё. Как на гитах, так и ведущий программист. Начинают тянуть одеяло на себя. А начинающим проектам — это будет даже полезно.
Так же гиты/свн вроде пробелы не учитывают (может ошибаюсь конечно). И в них тоже можно внедрить данные инструкции. Что кстати и делается например с пробелами.
И я же говорю про возможность форматировать согласно/против стайлгайда, а не весь код.
Я не могу понять вы против чего именно? Что не так с идеей. Взять например jsfiddle — там есть кнопочка «сделать заябись». В ДримВьивере мне показывали такую же кнопку.
А есть отдельные пакеры/минимизаторы. Крайности есть.
Что, неуж-то сложно сделать автозамену открывающейся скобки (начало строки/ конец)
Табы и пробелы в начале строки?
Нет. При использовании одного стиля люди не портят чужой код.
Но над проектом могут работать разные команды. Проект может быть публичным. Как быть разным командам?
Только в одном проекте они не должны пересекаться.
Не всегда это возможно. Иногда проекты используют разные чужие наработки/библиотеки/еtс.
Человек, который не способен усвоить стайлгайд, хороший код не напишет.
А вы уверены, что вы пишите именно по стайгайлу?
Вперед! Рекомендую начинать с создания ИИ.
Почему сразу ИИ? Обычные регулярки.
Оказывается уже есть ИИ.
Так потеряешь историю и blame из-за форматирования. Лучше уж с другим стилем мириться.
Ну не смертельно. Я не предлагаю менять константы, CamelCase и тому подобное (хотя можно и с этим рискнуть)
Я говорю за табы/пробелы, скобочки (форматирование). И если у другого разработчика будет тоже стоять своё форматирование, то оно просто восстановится как ему удобно.
При этом табы уже практические во всех программах можно отстраивать. В некоторых есть автоформатирование, но как заложили производители.
Почему не довести до настройки этого пользователем?
Я говорю за табы/пробелы, скобочки (форматирование). И если у другого разработчика будет тоже стоять своё форматирование, то оно просто восстановится как ему удобно.
При этом табы уже практические во всех программах можно отстраивать. В некоторых есть автоформатирование, но как заложили производители.
Почему не довести до настройки этого пользователем?
Это передвинет строки, в дифе весь код будет считаться изменённым и принадлежать вашему перу и мы лишаемся всех возможностей система контроля версий, так как она становиться больше похожа на бэкапы. Это смертельно для любого серьёзного проекта, который разрабатывает более одного человека.
Выше уже писал. Можно записывать первоначальное состояние и возвращать его при сохранение/
Измененные куски не сохранятся, ибо они изменились. Но приобретут общий вид.
Измененные куски не сохранятся, ибо они изменились. Но приобретут общий вид.
В теории да, кодефиксером можно проходить при открытии и применять свой стиль, затем перед коммитом приводить в командный стиль.
На практике, вот как эта фраза выглядит после перевода на английский и затем с анлийского на русский в google translate
— В теории да, кодефиксером могут быть проведены на открытии и применить ваш стиль, то перед тем, чтобы привести команду стиле.
На практике, вот как эта фраза выглядит после перевода на английский и затем с анлийского на русский в google translate
— В теории да, кодефиксером могут быть проведены на открытии и применить ваш стиль, то перед тем, чтобы привести команду стиле.
% hg help annotate
<…>
-w --ignore-all-space игнорировать пробельные символы при сравнении строк
-b --ignore-space-change игнорировать изменения в количестве пробельных
символов
-B --ignore-blank-lines игнорировать изменения, состоящие только из пустых
строк
<…>
hg help annotate? Другой вопрос, что их нельзя использовать вместе с языками, где важны отступы. И такой возможности нет в git, bazaar и svn. И наверняка почти во всех остальных VCS. Против изменений «скобочек» эти ключи также не помогут.Так что идея в целом плохая. Но история, тем не менее, в Mercurial «потеряется» не фатально.
Вот это ад.
Эта картинка как бы намекает нам на то, что 47% процентов Java-программистов Java Code Conventions не читали.
Эта картинка как бы намекает нам на то, что 47% процентов Java-программистов Java Code Conventions не читали.
не все так просто, например
final static Logger logger = Logger.getLogger(...);
это не полноценная константа, т.е. объект не является immutable, так что нет смысла писать ее капсом
final static Logger logger = Logger.getLogger(...);
это не полноценная константа, т.е. объект не является immutable, так что нет смысла писать ее капсом
Эээ а функции вот так никто не пишет?..
С переносом строки в смысле?
int myFunc()
{
//...
}
С переносом строки в смысле?
Хотелось бы по PHP еще такое же увидеть.
Забавно, что в примерах с табуляцией на сайте всё равно использованы пробелы. И уверен, какая-то часть людей, использующих пробелы, по факту пользуется табуляцией, автоматически заменяемой пробелами редактором.
Естественно, или вы предлагаете все пробелы ставить руками?
Уверен, что эта часть людей просто огромна.
Холивар «пробелы» вс «табуляция» о том, что должно быть в исходниках, а не отом как это вводить. Плюс умные ИДЕ вообще избавляют от необходимости ввода в подавляющем большинстве случаев, формируя отступы сами (стиль задается в настройках).
void A::F() {
/* blah */
}
> Египетский стиль.
Всю жизнь это называлось K&R стиль.
А расшифровывалось оно всю жизнь — ...?
Керниган и Ритчи.
Нынче на хабре минусуют незнание? Ок, не буду здесь ничего спрашивать.
Нынче на хабре минусуют незнание?
Я тут ни при чём. Могу плюс поставить, если это для тебя имеет большое значение.
Ок, не буду здесь ничего спрашивать.
Это зависит от того, что для тебя важнее получить — интересующие сведенья или плюсики.
<holуwar>
Руки бы поотрывал :-(
Руки бы поотрывал :-(
Скрытый текст
</holуwar>
Вам возможно покажется, что я начинаю холивар. Но я не понимаю какимы довыдами руководствуются люди предпочитающие пробелы.
У меня в редакторе стоит TAB равный 2 пробелам. У моего коллеги Николая — 4 пробелам. Его код, кажется мне ужасным. Ему мой. Но ему нравится. Мне мой тоже. Когда я открываю файл написанный его рукой, он выглядит точно так же как если бы я его писал. То есть, те же 2 пробела. То же самое с его стороны. Я счастлив. Он счастлив.
Когда я копирую код, где отступы сделаны в ввиде пробелов, то мне приходится конвертировать их в табы. Пустяки, это одна команда, я смогу с этим жить. Но у моего коллеги Ивана — отступы в пробелах. Там их три. А в коде, который он копирует, их 5. И теперь ему приходится каждую строчку двигать. И я вот сижу и думаю, нафига же он страдает. Он молчит, хмурится и правит. Может вот вы скажете?
У меня в редакторе стоит TAB равный 2 пробелам. У моего коллеги Николая — 4 пробелам. Его код, кажется мне ужасным. Ему мой. Но ему нравится. Мне мой тоже. Когда я открываю файл написанный его рукой, он выглядит точно так же как если бы я его писал. То есть, те же 2 пробела. То же самое с его стороны. Я счастлив. Он счастлив.
Когда я копирую код, где отступы сделаны в ввиде пробелов, то мне приходится конвертировать их в табы. Пустяки, это одна команда, я смогу с этим жить. Но у моего коллеги Ивана — отступы в пробелах. Там их три. А в коде, который он копирует, их 5. И теперь ему приходится каждую строчку двигать. И я вот сижу и думаю, нафига же он страдает. Он молчит, хмурится и правит. Может вот вы скажете?
Что в его любимом редакторе/IDE должна быть возможность автоматической установки отступов. Или хотя бы поиск и замена в выделенном тексте. Проблема, о которой вы говорите, решается и очень легко, по крайней мере в Vim.
Тем не менее это проблема, требующая решение. Всегда приятней же, когда из коробки все работает как надо :-)
Проблема решается принятием единого стандарта у команды.
Есть еще сторонние библиотеки, есть «примеры кода» и копипасты из чужих наработок.
Сторонние либы обычно идут как черные ящики, как они написаны для использования особо не важно.
«Примеры кода» после копипаста лучше сразу отформатировать по правилам проекта, куда попипаста и была сделана.
Так что не вижу особых проблем поддерживать в проекте единый стиль, если все разработчики между собой договорились.
«Примеры кода» после копипаста лучше сразу отформатировать по правилам проекта, куда попипаста и была сделана.
Так что не вижу особых проблем поддерживать в проекте единый стиль, если все разработчики между собой договорились.
«В теории, практика и теория это одно и то же. На практике это не так» (с)ктототам.
Величина таба зависит от настроек редактора. Если же посмотреть код в другом редакторе (или на гитхабе, к примеру) — код будет выглядеть по другому. Пробелы обеспечивают единообразие в этом плане, и это хорошо. А привыкнуть можно. К тому же, есть стайл гайды для разных языков. У ruby отступ = 2 пробела, к примеру. И использовать табы — дурной тон.
Величина таба зависит от настроек редактора. Если же посмотреть код в другом редакторе (или на гитхабе, к примеру) — код будет выглядеть по другому. Пробелы обеспечивают единообразие в этом плане, и это хорошо. А привыкнуть можно. К тому же, есть стайл гайды для разных языков. У ruby отступ = 2 пробела, к примеру. И использовать табы — дурной тон.
leMar как раз об этом и говорил. Только в положительном ключе: у него и его коллеги код с табуляцией выглядит по‐разному, так, как им обоим больше нравится.
А на «общие» руководства по стилю написания можно забить, используя свои. Их тоже не боги писали. Надо только принять во внимание, что в открытом проекте так можно отпугнуть часть разработчиков.
А на «общие» руководства по стилю написания можно забить, используя свои. Их тоже не боги писали. Надо только принять во внимание, что в открытом проекте так можно отпугнуть часть разработчиков.
А на гитхабе или битбакете код тоже выглядит так, как им ОБОИМ больше нравится? :) Ну и «на «общие» руководства по стилю написания можно забить, используя свои» — это плохая идея. Не боги писали, конечно. Но лучше придерживаться общих правил, тогда код в разных проектах и у разных людей выглядит одинаково, и это хорошо.
На github можно настроить величину табуляции.
Ничего хорошего в том, чтобы код выглядел в разных проектах одинаково, я не вижу. Человечество выживает за счёт разнообразия, а не за счёт единственности. Единственное но: если вы используете не тот стиль именования, что принят в некотором языке, то код в проекте будет выглядеть неоднородным за счёт внешних библиотек. А скобки, отступы, длина строк, способ разбиения длинных строк и тому подобное можно иметь какими угодно.
Ничего хорошего в том, чтобы код выглядел в разных проектах одинаково, я не вижу. Человечество выживает за счёт разнообразия, а не за счёт единственности. Единственное но: если вы используете не тот стиль именования, что принят в некотором языке, то код в проекте будет выглядеть неоднородным за счёт внешних библиотек. А скобки, отступы, длина строк, способ разбиения длинных строк и тому подобное можно иметь какими угодно.
А вы на гитхабе исходники правите что ли? Я лично на гитхабе только мельком отдельные файлы смотрю, а потом делаю клон и работаю себе спокойно.
При чем вы говорите не о проблемах табов, а о том, что кто-то их нормально не поддерживает. Завтра ситуация изменится и гитхаб будет предпочитать табы, сразу все проекты свои переформатируете?
При чем вы говорите не о проблемах табов, а о том, что кто-то их нормально не поддерживает. Завтра ситуация изменится и гитхаб будет предпочитать табы, сразу все проекты свои переформатируете?
На гитхабе я смотрю пулы, причем довольно много. Я говорил о том, что многие предпочитают однообразие. Пробелы, в отличие от табов, его обеспечивают.
Каким образом, если вы привыкли к 4м, а там по 2? В чем единообразие то? Без оглядки на гитхаб если говорить, то как раз табы обеспечивают единообразие, так как таб это неделимая единица без определенной ширины, в отличии от 2x/4x/Xx пробелов
Для этого и есть конвеншены. Договорились использовать 2 — используем 2 все. Каким макаром табы обеспечивают однообразие? Я у себя в редакторе могу какую угодно ширину таба задать, а потом же мой код в другом редакторе/сервисе выглядит по другому. Вроде бы уже все выяснили про этот момент.
Таким, что когда пишешь с табами: 1 отступ — это 1 таб ВСЕГДА, а ширину вы выставляете у себя в редакторе да. ЛЮБЫЕ исходники с табами теперь у вас отображаются так как вы привыкли.
При чем здесь конвенции, если вы сами про гитхаб говорите, предлагаете всех на планете обязать писать по какой-то 1й конвенции? Опять же, не вижу причин, почему в этой конвенции не написать табы а не 2/4 пробела
При чем здесь конвенции, если вы сами про гитхаб говорите, предлагаете всех на планете обязать писать по какой-то 1й конвенции? Опять же, не вижу причин, почему в этой конвенции не написать табы а не 2/4 пробела
Договорились использовать табуляцию — используем табуляцию все. В чём проблема?
Я не вижу, как табуляция сделает код единообразным. Я также не вижу, как пробелы сделают его таким. Convention’ы единообразным код сделают, что бы вы в них не написали про отступы.
Если вы про то, что в разных редакторах отступы будут занимать одинаковое место, то в этом я не вижу совершенно никакого смысла. Код в разных редакторах всё равно будет выглядеть по‐разному; и даже в одном редакторе при разных настройках. Почему бы тогда не написать, что код надо смотреть только в {какой‐то редактор} версии {какая‐то версия} с шрифтом {какой‐то моноширинный шрифт} и начертанием {какое‐то начертание} размера {какой‐то размер} и цветовой схемой {какая‐то цветовая схема} и настройками {какие‐то другие настройки редактора, влияющие на отображение}? Тогда код будет выглядеть единообразно. Если вас не пошлют.
Я не вижу, как табуляция сделает код единообразным. Я также не вижу, как пробелы сделают его таким. Convention’ы единообразным код сделают, что бы вы в них не написали про отступы.
Если вы про то, что в разных редакторах отступы будут занимать одинаковое место, то в этом я не вижу совершенно никакого смысла. Код в разных редакторах всё равно будет выглядеть по‐разному; и даже в одном редакторе при разных настройках. Почему бы тогда не написать, что код надо смотреть только в {какой‐то редактор} версии {какая‐то версия} с шрифтом {какой‐то моноширинный шрифт} и начертанием {какое‐то начертание} размера {какой‐то размер} и цветовой схемой {какая‐то цветовая схема} и настройками {какие‐то другие настройки редактора, влияющие на отображение}? Тогда код будет выглядеть единообразно. Если вас не пошлют.
Табы обеспечивают однообразие не со стороны «один и тот же код будет выглядеть одинаково у всех», а со стороны «Я буду видеть любой код одинаково», т.е. если у нас в команде принято 4, а в исходниках библиотеки, которую мы используем — 2, то это вызовет массу неудобств тем, кто привык к четырем. А за счет табов я буду видеть код так, как привычно мне, единообразие для меня.
Вы будете видеть код с табами одинаково только в своем редакторе. А посмотрите его на гитхабе — там табуляция как 8 пробелов. Посмотрите у друга за его ноутом в виме-емаксе-whatever — опять-таки, по другому выглядит. Я же хочу, чтоб код везде выглядил одинаково. Ну это просто разный подход, кому что как говорится.
Выше уже писали — на гитхабе/битбакете можно подстроить табуляцию под себя (хотя там вроде для гитхаба нюансы...). Однако что вы делаете чаще — смотрите у себя код, написанный разными людьми (с разными стилями) или же смотрите у друга? Как долго (и как много) вы смотрите код у друга относительно времени просмотра/количества кода, просматриваемого (и редактируемого) вами на вашем ПК?
У каждого этот баланс будет свой и поэтому к единому решению мы прийти не сможем.
У каждого этот баланс будет свой и поэтому к единому решению мы прийти не сможем.
Покажите пожалуйста, как это настраивается на гитхабе. В остальном согласен — тут нет единого решения. И стайл гайды для разных языков разные.
— Одеваем 3Д очки, с разной поляризацией.
— На работе ставим 3Д мониторы.
— Вносим небольшие изменения в редактор.
— Профит
Подходя к монитору друга в твоих очках будут 4 пробела, в очках друга 2.
:D
— На работе ставим 3Д мониторы.
— Вносим небольшие изменения в редактор.
— Профит
Подходя к монитору друга в твоих очках будут 4 пробела, в очках друга 2.
:D
На bitbucket «можно»: с помощью UserCSS в браузерах, поддерживающих tab-size (например, старая Opera с -o-tab-size и firefox с -moz-tab-size).
На гитхабе код с табуляцией выглядит не очень, т.к. она там 8 (а в diff — 2). 8 является стандартом для вывода на терминал, но в форматировании кода используется редко (имхо).
Не понятно почему гитхаб не даёт настроить величину табуляции и игнорирует нужды минимум 5-10% пользователей. (некоторые языки, по которым есть статистика, имеют общепринятые styling guides, и там процент пробелов большой, например в Ruby).
Собственно, гитхабы приходят и уходят, не вижу смысла переходить на пробелы в тех языках где я использую табы.
Не понятно почему гитхаб не даёт настроить величину табуляции и игнорирует нужды минимум 5-10% пользователей. (некоторые языки, по которым есть статистика, имеют общепринятые styling guides, и там процент пробелов большой, например в Ruby).
Собственно, гитхабы приходят и уходят, не вижу смысла переходить на пробелы в тех языках где я использую табы.
Потому что нифига это не работает, самый простой пример, допустим у вас в коде с двумя пробелами:
потом, вы понимаете что она выходит за границы в 80 или 100 символов, и вы решаете перенести часть аргументов
вам кажется что все выровнено, а вот коллега с 4-мя табами будет плеваться.
var functionThatTakesTooManyAnguments = function(argument1, argument2, argument3, argument4, argument5, argument6);
потом, вы понимаете что она выходит за границы в 80 или 100 символов, и вы решаете перенести часть аргументов
var functionThatTakesTooManyAnguments = function(argument1, argument2, argument3, argument4,
argument5, argument6);
вам кажется что все выровнено, а вот коллега с 4-мя табами будет плеваться.
Разделяйте отступы и выравнивание. Отступы можно делать чем угодно. Выравнивание нужно делать пробелами. Правда, настроить редактор, чтобы он разделял эти два понятия, обычно непросто.
И часто вообще невозможно. Когда в прошлый раз холиварил по этому вопросу, мне скинули ссылок на популярные опен-сорсные проекты, которые используют табы. После осмотра правил кодирования и исходников проекты разделились следующим образом:
Единственный способ правильно использовать табы, чтобы их размер реально можно было менять — это отступы табами, выравнивание пробелами. Такой способ я ещё ни разу в жизни не видел вживую. Если кто-то может привести пример крупного опен-сорсного проекта (то есть с большим количеством разработчиков и солидным объёмом кода, а не преимущественно индивидуальные поделки), то я буду рад расширить свой кругозор.
По-моему, этот идеальный способ реализуется только в лабораторных условиях, то есть внутри компаний, где есть полный контроль над средствами разработки и их настройками, и есть достаточно идеалистов, чтобы за кодом следить. В случае шарпа, например, обязательным становится наличие решарпера и правильной его конфигурации с расшариванием правил; нужно всех поголовно убедить переформатировать все изменённые файлы перед каждым коммитом.
На самом деле и пробелы, и табы — говно. :) И в том, и в другом случае требуется настройка редактора под конкретный проект: в одном случае нужно настроить размер отступа, в другом — смешанное форматирование. Один чёрт неудобно.
- Табы имеют строго фиксированный размер (2, 4, 8, кто во что горазд). Использовать редактор с другим размером таба запрещается. В этом случае холивара нет, так как пробельные символы на отображение не влияют, и все видят абсолютно одинаковый код. (Холивар переключается в русло размера отступа.)
- Табы имеют рекомендуемый размер (отступы не оговариваются или предлагается делать их пробелами). Проектов, где отступы пробелами идеально соблюдаются, чтобы можно было изменять размер таба на свой любимый, найдено не было. То есть де-факто размер таба опять фиксированный, и мы возвращаемся к первому пункту.
Единственный способ правильно использовать табы, чтобы их размер реально можно было менять — это отступы табами, выравнивание пробелами. Такой способ я ещё ни разу в жизни не видел вживую. Если кто-то может привести пример крупного опен-сорсного проекта (то есть с большим количеством разработчиков и солидным объёмом кода, а не преимущественно индивидуальные поделки), то я буду рад расширить свой кругозор.
По-моему, этот идеальный способ реализуется только в лабораторных условиях, то есть внутри компаний, где есть полный контроль над средствами разработки и их настройками, и есть достаточно идеалистов, чтобы за кодом следить. В случае шарпа, например, обязательным становится наличие решарпера и правильной его конфигурации с расшариванием правил; нужно всех поголовно убедить переформатировать все изменённые файлы перед каждым коммитом.
На самом деле и пробелы, и табы — говно. :) И в том, и в другом случае требуется настройка редактора под конкретный проект: в одном случае нужно настроить размер отступа, в другом — смешанное форматирование. Один чёрт неудобно.
В yii например отступы форматируются табами:
github.com/yiisoft/yii
github.com/yiisoft/yii
Глянул. Отступы только табами, у них жёсткий запрет на пробелы (см. yii-coding-standard/blob/master/Yii/ruleset.xml). Проблему с выравниванием они решили радикально — у них нет выравнивания. :)) Ну то есть «удлинённых» переносов, чтобы выровнять какой-то кусок с текстом на предыдущей строке — нет. Сами строки при этом часто достигают космической длины. Впрочем, проколы можно найти.
db/ar/CActiveRecord.php
К слову, при виде некоторых кусков кода хочется выстрелить себе в голову, лишь бы не видеть этого.
base/CComponent.php
db/ar/CActiveRecord.php
db/ar/CActiveRecord.php
private static $_models=array(); // class name => model
private static $_md=array(); // class name => meta data
private $_new=false; // whether this instance is new or not
private $_attributes=array(); // attribute name => attribute value
private $_related=array(); // attribute name => related objects
private $_c; // query criteria (used by finder only)
private $_pk; // old primary key value
private $_alias='t'; // the table alias being used for query
К слову, при виде некоторых кусков кода хочется выстрелить себе в голову, лишь бы не видеть этого.
base/CComponent.php
base/CComponent.php
public function raiseEvent($name,$event)
{
$name=strtolower($name);
if(isset($this->_e[$name]))
{
foreach($this->_e[$name] as $handler)
{
if(is_string($handler))
call_user_func($handler,$event);
elseif(is_callable($handler,true))
{
if(is_array($handler))
{
// an array: 0 - object, 1 - method name
list($object,$method)=$handler;
if(is_string($object)) // static method call
call_user_func($handler,$event);
elseif(method_exists($object,$method))
$object->$method($event);
else
throw new CException(Yii::t('yii','Event "{class}.{event}" is attached with an invalid handler "{handler}".',
array('{class}'=>get_class($this), '{event}'=>$name, '{handler}'=>$handler[1])));
// (...)
Ничто не идеально, я привел Yii не как пример для подражания, а как пример проекта, который вы просили.
Похоже, я криво сформулировал мысль. Я хочу увидеть крупный опен-сорсный проект, где соблюдается правило «отступы табами, выравнивание пробелами», чтобы можно было выставить любой размер таба. Табовые апологеты рассказывают о множестве инструментов, поддерживающих данную функцию, поэтому мне интересно увидеть такой идеальный проект вживую. :)
Я бы и сам переметнулся в лагерь табистов, но боюсь, что излишняя тяга к идеальному меня погубит, а подобные проекты — миф.
Я бы и сам переметнулся в лагерь табистов, но боюсь, что излишняя тяга к идеальному меня погубит, а подобные проекты — миф.
Вася с двухпробельными табами будет умещать большие деревья в ширину экрана. А Петя с четырёхпробельными будет тренироваться в искусстве горизонтального скролла.
В данном случае придется выбирать меньшее из зол.
На мой взгляд у проблемы нет однозначного решения.
Всплыла идея плагина к IDE, который сможет отличить перенос строки от новой строки и в зависимости от этого форматировать код. Скажем, в проекте рядом с файлом сохраняется метаинформация, в которой указано положение переносимой строки относительно первой строки, с которой начался перенос.
На мой взгляд у проблемы нет однозначного решения.
Всплыла идея плагина к IDE, который сможет отличить перенос строки от новой строки и в зависимости от этого форматировать код. Скажем, в проекте рядом с файлом сохраняется метаинформация, в которой указано положение переносимой строки относительно первой строки, с которой начался перенос.
А зачем вообще переносить? Ну то есть я тоже стараюсь избегать слишком длинных строк по возможности, но если уж в любом случае получается, то пусть будет. Есть какое-то разумное обоснование того, чтобы все до единой строки были <80 символов, ну кроме исторический конечно? С учетом еще того, что в редакторах обычно есть перенос символов?
Перенос во многих редакторах (в частности, в Vim) плохо выглядит.
Переносы я предлагаю использовать для печати кода, например, а в остальном строки стараюсь делать не большими, но без фанатизма. Опять же монитор позволяет побольше чем 80 симфолов вместить в строку, так что не вижу проблемы вообще.
Как на счёт вообще обходиться без выравнивания (если пробелы выравнивания совмещены с отступами, а не в середине строки)?
Даже если используем пробелы, те IDE которые смогут разобраться где отступ, и сколько он пробелов, не смогут отличить такое выравнивание от отступа.
var functionThatTakesTooManyAnguments = function(
argument1, argument2, argument3, argument4, argument5, argument6
);
Даже если используем пробелы, те IDE которые смогут разобраться где отступ, и сколько он пробелов, не смогут отличить такое выравнивание от отступа.
Через терминал работаете?
Не-не. Табы только для отступов. Выравнивание — ТОЛЬКО пробелы.
Прежде всего неопределенность длины строки. Вот есть, например, соглашение что длина строки не должна превышать 80 символов. С каким размером таба её считать? Далее неопределенность с отступами и выравниваниями.
Ну а нормальные IDE вполне корректно обрабатывают вставку фрагментов кода с другим стилем выравнивания и отступов.
Ну а нормальные IDE вполне корректно обрабатывают вставку фрагментов кода с другим стилем выравнивания и отступов.
у таба размер не определен, но как правило это не больше 4 пробелов, из этого расчета и считайте, если есть такая необходимость
>> С каким размером таба её считать?
Размер Таба определяется. У меня это 2 пробела. У вас может быть 4. Вы сами это ставите.
>> Далее неопределенность с отступами и выравниваниями.
Какая такая неопределенность? Если у вас код с табами, и у меня, то он у обоих будет выглядеть так как у нас установлено в редакторе. А если у вас в пробелах и у меня в пробелах, но кол-во пробелов разное, то все равно будет по разному. Табы-то как раз и дают определенность.
Размер Таба определяется. У меня это 2 пробела. У вас может быть 4. Вы сами это ставите.
>> Далее неопределенность с отступами и выравниваниями.
Какая такая неопределенность? Если у вас код с табами, и у меня, то он у обоих будет выглядеть так как у нас установлено в редакторе. А если у вас в пробелах и у меня в пробелах, но кол-во пробелов разное, то все равно будет по разному. Табы-то как раз и дают определенность.
Вы сами это ставите.
У меня это два пробела, а у ревьювера восемь и он зарубает мой код с причиной «нарушение code style convention», потому что у него строка вылазит за 80 символов, а у меня нет.
Какая такая неопределенность?
Визуально табы и пробелы не отличаются, и при выравнивании строки с отступом сложно однозначно сказать где кончаются табы и начинаются пробелы. Нарушено ли соглашение, по которому сначала идет отступ табами, а потом выравнивание пробелами, на взгляд не скажешь. Не затесалось ли несколько случайных пробелов в отступах — тоже.
Вы же все равно отступы ставите клавишой Таб. И чтобы писать код под требования, вам необходимо это настроить. Если у вас и ревювера стоят табы — проблемы нет. Я говорю об общей правильности и удобстве табов, а не о частной.
Нет, я их ставлю клавишей Ентер :)
И точно так же мне нужно настраивать IDE на количество пробелов в одном уровне отступа — в чем профит от табов?
И точно так же мне нужно настраивать IDE на количество пробелов в одном уровне отступа — в чем профит от табов?
Профит от табов, о общем-то как и от пробелов, появляется когда их используют все в проекте) Если кто-то форматирует так, а кто-то иначе, то проблемы возникают и у тех и других. Другое дело, что с табами хотябы нет еще и деления на 2/4 пробела, вот и все, 1 отступ — 1 таб, вот и все.
У меня это два пробела, а у ревьювера восемь и он зарубает мой код с причиной «нарушение code style convention», потому что у него строка вылазит за 80 символов, а у меня нет.
Мне только что пришла в голову любопытная идея: редактор, который динамически меняет размер табов в зависимости от максимальной длины строки в блоке кода. Не знаете, может уже где и реализовано?
По-моему, это просто убойный аргумент против табов. При большом уровне вложенности, скажем 5, мы имеем разницу между табом в 2 пробела и табом в 8 пробелов — 30 символов. Иными словами, максимальная строки кода на строке 5м уровнем отступа при просмотре с табом в 8 символов — 40 символов, а при 2 символах на таб — 70 символов. Код с пятым уровнем отступа, в котором 80 символов на строку при табе в 2 символа на 8-пробельном табе будет занимать 110 символов.
Однозначный конфликт. В итоге, все в команде вынуждены работать с одинаковым размером таба и все профиты использования таба улетучиваются.
Однозначный конфликт. В итоге, все в команде вынуждены работать с одинаковым размером таба и все профиты использования таба улетучиваются.
Это убойный аргумент против использования больших уровней вложенности. А вы вместо лечения болезни предлагаете лечить симптомы.
5 — это не большой уровень вложенности.
1 — класс.
2 — метод.
3 — условие.
4 — цикл.
5 — ещё условие.
Я согласен, что большие уровни вложенности — зло. Но 5 — это ещё пограничная зона, где не обязательно нужен рефакторинг. Но и на меньших уровнях есть эта разница. Всё равно, у одного строка 80 символов, а у другого — 104.
1 — класс.
2 — метод.
3 — условие.
4 — цикл.
5 — ещё условие.
Я согласен, что большие уровни вложенности — зло. Но 5 — это ещё пограничная зона, где не обязательно нужен рефакторинг. Но и на меньших уровнях есть эта разница. Всё равно, у одного строка 80 символов, а у другого — 104.
А с другой стороны, у одного монитор широкий, а у другого — высокий.
Мне кажется, что проблема на самом деле в том, что современные редакторы плохо заточены под табы. Ведь легко можно было бы сделать такой редактор, который бы предупреждал при превышении длины строки «если бы табы были как два пробела», но при этом позволял выставлять любой размер табов для обеспечения комфорта именно того человека, который пишет код (и может иметь монитор любой ширины). А в отсутствие таких «умных» редакторов, да, приходится выкручиваться.
Мне кажется, что проблема на самом деле в том, что современные редакторы плохо заточены под табы. Ведь легко можно было бы сделать такой редактор, который бы предупреждал при превышении длины строки «если бы табы были как два пробела», но при этом позволял выставлять любой размер табов для обеспечения комфорта именно того человека, который пишет код (и может иметь монитор любой ширины). А в отсутствие таких «умных» редакторов, да, приходится выкручиваться.
Мне кажется, что проблема в том, что современные редакторы слишком заточены под табы в их очень узком понимании «перейти к следующей позиции, кратной N (где N по умолчанию 8)», в то время как изначально было «перейти к следующей позиции табуляции (где позиции табуляции задаются заранее и динамически)».
А с другой стороны, у одного монитор широкий, а у другого — высокий.Речь не о мониторах, речь о соглашениях по стандартам кодирования. VolCh описывает как раз такую ситуацию, когда код, написанный по стандарту, внезапно у ревьюера становится нарушающим стандарты.
Если в стандарте сказано «при табах такой-то длины код должен вмещаться в такое-то количество столбцов», а у меня табы меньше и всё вмещается, то виноват, разумеется, я. Другое дело, что это не повод мне смотреть на длиннющие табы.
В идеале, у редактора должно быть две опции: длина таба в пробелах и длина таба в пикселях. Первая — для обеспечения соответствия стандарту; вторая — для моего комфорта.
В идеале, у редактора должно быть две опции: длина таба в пробелах и длина таба в пикселях. Первая — для обеспечения соответствия стандарту; вторая — для моего комфорта.
Если в стандарте сказано «при табах такой-то длины код должен вмещаться в такое-то количество столбцов», а у меня табы меньше и всё вмещается, то виноват, разумеется, я.
Иными словами, чтобы не нарушать стандарты я вынужден проверять все коммиты на длину строки (т.к. она сильно варьируется от конкретной глубины вложенности). Как-то слишком много возни для столь незначительного профита (который, кстати, в основном, дело привычки).
Нет, у вас редактор должен автоматически проверять. Сейчас ведь вы 80 столбцов тоже не ручками отсчитываете?
Ну, как вы заметили, проблема в том, что таких редакторов пока что не существует.
Вот мы и пришли к тому, что я заметил то, что я заметил.
А по теме — если таких редакторов нет, надо такие редакторы написать. На досуге попробую сделать плагин к Emacs.
А по теме — если таких редакторов нет, надо такие редакторы написать. На досуге попробую сделать плагин к Emacs.
Написать дополнение к Vim, проверяющее ширину текста при табуляции, равной восьми — дело пяти минут.
function FindTooLongLines()
if &textwidth == 0
return 0
endif
let saved_winview=winsaveview()
let saved_tabstop=&tabstop
let saved_lazyredraw=&lazyredraw
set tabstop=8 lazyredraw
let ret=0
let pattern=printf('\%%>%uv.*', &textwidth)
try
1
while search(pattern, 'We')
echohl ErrorMsg
echomsg printf('Line %u is too long: %s', line('.'), substitute(getline('.'), '^\s*', '', ''))
echohl None
let ret=1
endwhile
finally
let &tabstop=saved_tabstop
let &lazyredraw=saved_lazyredraw
call winrestview(saved_winview)
endtry
return ret
endfunction
autocmd BufWritePre * :if FindTooLongLines()|throw 'Too long lines found'|endif
Да-да. Пойдите попрограммируйте на JavaScript'е, потом поговорим про уровни вложенности.
UFO just landed and posted this here
Языков много и у каждого языка есть свои code conventions, например когда я пишу на java, первую букву публичного методов я пишу с маленькой буквы, а вот на C# с большой. Но, что могу сказать точно, на всех языках, константы надо писать с большой буквы и отступы табами это зло.
UFO just landed and posted this here
Влиться это одно, но душа кровью может не перестать обливаться, каждый раз когда вставляешь табуляцию :)
Меня всегда удивляет количество сил, которое тратится на обсуждение такой незначительной темы, как отступов, выравнивания, пробелов, скобочек.
Один из законов Паркинсона в действии. Очень советую читать не на Википедии, а тут.
И при чём тут это? Не вижу связи.
Скорее проблема в том что табы и пробелы не совместимы. В одном проекте должны быть или табы или пробелы. Поэтому люди и спорят что лучше, т.к. выбор одних ограничит свободы других.
Если в одном проекте кто-то поставит фигурную скобку не на той строке, это будет меньшая катастрофа чем смешивание табов с пробелами.
Если Вася Пупкин в своём личном проекте будет использовать табы или пробелы мне совершенно всё равно, так же я не буду делать никаких выводов а качестве его кода и настаивать на том чтобы он сменил символ отступов.
Финансовый комитет будет до хрипоты спорить о том, как потратить 100$ и легко согласится с выделением суммы в несколько миллионов.
Скорее проблема в том что табы и пробелы не совместимы. В одном проекте должны быть или табы или пробелы. Поэтому люди и спорят что лучше, т.к. выбор одних ограничит свободы других.
Если в одном проекте кто-то поставит фигурную скобку не на той строке, это будет меньшая катастрофа чем смешивание табов с пробелами.
Если Вася Пупкин в своём личном проекте будет использовать табы или пробелы мне совершенно всё равно, так же я не буду делать никаких выводов а качестве его кода и настаивать на том чтобы он сменил символ отступов.
Есть множество случаев, когда выбор одних ограничит свободы других, и тем не менее по их поводу никто не устраивает холивар. Смысл был в том, что по поводу простых вещей — таких, как табы/пробелы — у каждого человека есть своё мнение. Больше мнений — жарче спор.
И про скобку вы правильно вспомнили — разные виды скобок совместимы, а холивар идёт.
И про скобку вы правильно вспомнили — разные виды скобок совместимы, а холивар идёт.
UFO just landed and posted this here
UFO just landed and posted this here
>Почему это так важно, где будет стоять фигурная скобка, открывающая описание тела метода, например?
Для программиста-одиночки это не важно. Для команды — это очень актуальный вопрос. Чтобы каждый коммит не сопровождался попутным переформатированием исходника. Обычно в коллективном проекте форматирование должно сразу оговариваться и соблюдаться всеми. Понятно, что разные люди предпочитают разные стили, поэтому кому-то приходится уступать. Но бесследно такое самоограничение не проходит и со временем начинается спор о том, какой метод предпочтительнее :)
/me пишет без пробела, в snake-style, с фигурной скобкой в начале следующей строки и с табуляциями по 4 пробела :)
Для программиста-одиночки это не важно. Для команды — это очень актуальный вопрос. Чтобы каждый коммит не сопровождался попутным переформатированием исходника. Обычно в коллективном проекте форматирование должно сразу оговариваться и соблюдаться всеми. Понятно, что разные люди предпочитают разные стили, поэтому кому-то приходится уступать. Но бесследно такое самоограничение не проходит и со временем начинается спор о том, какой метод предпочтительнее :)
/me пишет без пробела, в snake-style, с фигурной скобкой в начале следующей строки и с табуляциями по 4 пробела :)
Я использую в JavaScript двойные кавычки для строк с сообщенями и ординарные для «технических» строк (например, имени поля, если по каким-то причинам записываю его строкой).
Тоже хотел заметить в языках, где для строк можно использовать и одинарные, и двойные кавычки, часто их разделяют семантически: одинарные — для идентификаторо-образных строк, двойные — для текста на естественных языках. Хотя в PHP, например, строки функционально различаются, и выбора в некоторых случаях не остаётся, в тех случаях, когда выбор есть, я предпочитаю придерживаться описанного выше правила.
Поэтому статистика по кавычкам явно неполностью описывает ситуацию.
Поэтому статистика по кавычкам явно неполностью описывает ситуацию.
А пробел между круглой и фигурной скобкой?
Пробел + скобки с новой строки.
/me@PHP
class MyClass
{
const MY_CONST = '...';
public function fooBar($baz)
{
...
if ($baz) {
...
}
return ...;
}
}
А зачем пустые строки возле скобок класса?
Абсолютно верно, все бы так.
github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
Так, подавляющее большинство (86%) программистов C# открывают фигурную скобку на новой строке. В Java всё наоборот...Это как-то связано с настройками IDE по умлолчанию?
Вообще такой разброс — это плохо. Ведь практически для любого языка есть стандарт оформления кода (иногда к сожалению несколько).
Скорее всего люди начинают программировать, не зная о существовании таких стандартов, а потом не могут переучиться и возводят привычное им написание до уровня «так общепринято», начинают находить в нем преимущества, красоту и простоту.
Это как игнорировать правила орфографии. Да, смысл сохраняется, только бы знающему человеку на глаза не попадало.
Скорее всего люди начинают программировать, не зная о существовании таких стандартов, а потом не могут переучиться и возводят привычное им написание до уровня «так общепринято», начинают находить в нем преимущества, красоту и простоту.
Это как игнорировать правила орфографии. Да, смысл сохраняется, только бы знающему человеку на глаза не попадало.
Sign up to leave a comment.
Какие стили оформления кода предпочитает аудитория Гитхаба?