Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Чем помогает стандарт?
В команде можно (и нужно) его принять за основу и всегда проверять код на соответствие ему.
Чем плохи свои изменения стандартов?
Собственно ничем, но, отступив от принятых норм один раз, очень легко уйти далеко в сторону. Если в команде все понимают зачем принят принцип SmartTabs и он не вызывает сомнений, то проблемы нет. В противном случае лучше уже использовать PSR.
В команде можно (и нужно) его принять за основу и всегда проверять код на соответствие ему.
Чем плохи свои изменения стандартов?
Собственно ничем, но, отступив от принятых норм один раз, очень легко уйти далеко в сторону. Если в команде все понимают зачем принят принцип SmartTabs и он не вызывает сомнений, то проблемы нет. В противном случае лучше уже использовать PSR.
Если дело об одной команде и нормах принятых в ней это да, но работая в такой команде привыкаешь к их правилам (особенно плохо если ты новичок был когда пришел). А потом когда уходишь из этой команды и приходишь в другую где разработка полностью соответствует PSR-2 стандарту, становится уже труднее, приходится опять переучиваться.
Я просто всегда был мнения, что стандарты 100 раз продумывают прежде чем издавать, возможно с этим пунктом так и было, возможно что в стандарте не расписали более подробно этот пункт и он остался не до конца понятым массами.
Мне тут подсказали одно интересное решение, можно пользоваться табами для отступов, а во время коммита GIT будет проводить конвертацию табов в 4 пробела. А при каждом получении новых данных с сервера проводится обратная конвертация пробелов в табы. Тем самым в сервисе контроля версий код всегда валиден PSR-2, а локальные копии у каждого программиста могут быть какими угодно (как кому больше нравится)
Я просто всегда был мнения, что стандарты 100 раз продумывают прежде чем издавать, возможно с этим пунктом так и было, возможно что в стандарте не расписали более подробно этот пункт и он остался не до конца понятым массами.
Мне тут подсказали одно интересное решение, можно пользоваться табами для отступов, а во время коммита GIT будет проводить конвертацию табов в 4 пробела. А при каждом получении новых данных с сервера проводится обратная конвертация пробелов в табы. Тем самым в сервисе контроля версий код всегда валиден PSR-2, а локальные копии у каждого программиста могут быть какими угодно (как кому больше нравится)
Почему посчитали пробелы предпочтительнее табов — науке это неизвестно, но если отбросить вариант с «GIT и IDE сами разберутся», есть большАя доля вероятности что в проект с пробелами попадёт пулл-реквест с табами и наоборот.
Стандарт существует чтобы унять разброд и шатание, ни больше ни меньше. Если вам нравятся табы — используйте табы, но в паблик при заявленной поддержке стандарта будьте добры отдать всё в соответствии со стандартом.
Стандарт существует чтобы унять разброд и шатание, ни больше ни меньше. Если вам нравятся табы — используйте табы, но в паблик при заявленной поддержке стандарта будьте добры отдать всё в соответствии со стандартом.
Пост писался как раз чтобы попытаться разобраться почему именно пробелы выбрали авторы, а не табы.
Я понимаю, что стандарт это хорошо, но разброд и шатание не прекратятся до тех пор пока люди не поймут почему стоит писать именно так и никак иначе, ведь к другим пунктам стандарта претензий нет (например к пробелам перед и после открывающихся скобок).
А так идея про автоматическую конвертацию во время синхронизаций с сервером мне кажется все более отличной. Тут и не нужно переучиваться и при этом твой код в паблике соответствует стандарту. Как говорится и волки сыти и овцы целы )
P.S. судя по моей карме и рейтингу поста, разброд и шатание не собирается униматься )
Я понимаю, что стандарт это хорошо, но разброд и шатание не прекратятся до тех пор пока люди не поймут почему стоит писать именно так и никак иначе, ведь к другим пунктам стандарта претензий нет (например к пробелам перед и после открывающихся скобок).
А так идея про автоматическую конвертацию во время синхронизаций с сервером мне кажется все более отличной. Тут и не нужно переучиваться и при этом твой код в паблике соответствует стандарту. Как говорится и волки сыти и овцы целы )
P.S. судя по моей карме и рейтингу поста, разброд и шатание не собирается униматься )
Стандарт как раз существует для того что бы не нужно было никуда переучиваться.
Борьба по поводу табов и пробелов шла ожесточённая, но преимущества пробелов победили, и поэтому таков стандарт. Не все важные факторы выбора в пользу пробелов были приведены в стандарте, потому что стандарт, не для разъяснения причин выбора того или иного решения.
Про автозамену табов на пробелы при пуше, это вообще бред сивой кобылы, зачем такое может понадобиться? Если только хочется специально проблем привнести в разработку, то это самое нормально решение.
Борьба по поводу табов и пробелов шла ожесточённая, но преимущества пробелов победили, и поэтому таков стандарт. Не все важные факторы выбора в пользу пробелов были приведены в стандарте, потому что стандарт, не для разъяснения причин выбора того или иного решения.
Про автозамену табов на пробелы при пуше, это вообще бред сивой кобылы, зачем такое может понадобиться? Если только хочется специально проблем привнести в разработку, то это самое нормально решение.
" А потом когда уходишь из этой команды и приходишь в другую где разработка полностью соответствует PSR-2 стандарту, становится уже труднее, приходится опять переучиваться."
Выгоднее привыкать быстро переучиваться, на мой взгляд, чем привязываться к чему-то «правильному». Новый стандарт кодирования, хоткеи, новая IDE… Потом на стандарт кодирования и т.п. условности становится уже все равно. Какой принят в фреймворке, на таком и пишешь. Привыкаешь быстро усваивать новые условия кодирования.
Выгоднее привыкать быстро переучиваться, на мой взгляд, чем привязываться к чему-то «правильному». Новый стандарт кодирования, хоткеи, новая IDE… Потом на стандарт кодирования и т.п. условности становится уже все равно. Какой принят в фреймворке, на таком и пишешь. Привыкаешь быстро усваивать новые условия кодирования.
Все просто — PSR-2 делался с оглядкой на существующие стили кодирования в популярных фреймворках и компонентах, одной из задач была фиксация существующего статус-кво. А в подавляющем большинстве PHP-фреймворков и библиотек использовались 4 пробела — просто так сложилось.
Лично я не вижу разницы — работал и со смарт-табами, и с пробелами, никаких проблем в обоих случаях.
Лично я не вижу разницы — работал и со смарт-табами, и с пробелами, никаких проблем в обоих случаях.
Вот вам пример когда SmartTabs садится в лужу:
Плюс согласитесь, наличие строк типа «ваша IDE должна отображать таб как 4 пробела» это странно для стандарта написания кода, а цель стандарта — единообразие
class MyClass
{
/**
* Usage example:
* <code>
* MyClass::doFoo(function () {
* // oh shi~, indentation, what should I use????
* FFUU$a = 0;
* }
* </code>
*/
static public function doFoo()
Плюс согласитесь, наличие строк типа «ваша IDE должна отображать таб как 4 пробела» это странно для стандарта написания кода, а цель стандарта — единообразие
Если я правильно понял, имеется ввиду отступы в примере, который в комментарии. Ну дак тут SmartTabs не поможет, но там как раз и смысл весь в том что табы для отступов от начала строки, а дальше уже только пробелы.
В этом примере согласно SmartTabs нужно делать пробелами отступы, да и вряд ли кто-то будет копировать этот код примера чтобы его использовать, ведь после копирования все равно останутся в начале строк знаки "*" от комментария.
В этом примере согласно SmartTabs нужно делать пробелами отступы, да и вряд ли кто-то будет копировать этот код примера чтобы его использовать, ведь после копирования все равно останутся в начале строк знаки "*" от комментария.
Вот что нашел, жаль данные устарели, вот бы сейчас посмотреть как изменилась ситуация
http://sideeffect.kr/popularconvention
P.S. хм, ссылка не ставится нормально, придется копировать, извините.
http://sideeffect.kr/popularconvention
P.S. хм, ссылка не ставится нормально, придется копировать, извините.
На мой взгляд, вполне разумное объяснение, почему пробелы, а не табы, дано в документации к checkstyle:
Rationale:
- Developers should not need to configure the tab width of their text editors in order to be able to read source code.
- From the Apache jakarta coding standards: In a distributed development environment, when the commit messages get sent to a mailing list, they are almost impossible to read if you use tabs.
Developers should not need to configure the tab width of their text editors in order to be able to read source code.Зато если используются табы для отступов, то разработчик получает возможность задать удобный для себя размер. Да и вообще, во всех редакторах по умолчанию стоит какое-то значение, так что если кому-то лень задавать свою ширину таба — можно использовать знаение по умолчанию. Так себе причина. (При условии, конечно же, что табы используются только для отступов, а для выравнивания — пробелы).
From the Apache jakarta coding standards: In a distributed development environment, when the commit messages get sent to a mailing list, they are almost impossible to read if you use tabs.Требует пояснения или примера.
Мимо. Ответ здесь.
Я думаю под диффами имеется ввиду merge изменений. Представьте код с пробелами — все ок, с табами прийдется заново выстраивать форматирование.
Прочитав все комментарии и изучив тот ресурс с анализом сорцов гитхаба решил пересилить себя и перейти на пробелы вместо табов )) Все таки стандарт это хорошо и хочется уже писать полностью валидный PSR-2 код, чтобы вошло все это в привычку и в будущем не было уже никаких проблем.
Вы ещё не учли такой вариант. Есть два разработчика: один использует табы, другой использует пробелы.
Далее рассмотрим два варианта:
Это может быть проблемой. Хотя, современные VCS-системы (git, SVN и пр.) должны не обращать внимание на замену пробельных символов.
Как говорили выше, в команде обычно есть однозначная договорённость по отступам, и они используются последовательно.
Но если это открытый проект с большим количеством контрибьюторов, то будет постоянная каша в коде и ругань в обсуждении.
А если принять стандарт (который, к тому же, и меет рациональное обоснование), то вопросов не будет:
— Мы на проекте используем стандарт PSR-2.
— Круто! Пойду менять настройки своей IDE! **Радостно убежал**
Далее рассмотрим два варианта:
- Каждый разработчик просто молча использует свой стиль. Таким образом, в коде будет каша из пробелов и табов.
- IDE будет ругаться на непоследовальное использование пробелов и табов и предлагать исправить. Будут постоянные замены табов на пробелы и наоборот — при каждом коммите.
Это может быть проблемой. Хотя, современные VCS-системы (git, SVN и пр.) должны не обращать внимание на замену пробельных символов.
Как говорили выше, в команде обычно есть однозначная договорённость по отступам, и они используются последовательно.
Но если это открытый проект с большим количеством контрибьюторов, то будет постоянная каша в коде и ругань в обсуждении.
А если принять стандарт (который, к тому же, и меет рациональное обоснование), то вопросов не будет:
— Мы на проекте используем стандарт PSR-2.
— Круто! Пойду менять настройки своей IDE! **Радостно убежал**
Я вот никогда этого пункта не понимал. Табы как раз и предназначены для универсальности: кому-то нравится 2 пробела, кому-то 4. Просто ставишь таб, а у каждого он означает свое.
Но комьюнити во многих языках проголосовало за пробелы (php, ruby) и приходится смириться
Но комьюнити во многих языках проголосовало за пробелы (php, ruby) и приходится смириться
Согласен с вами. С пробелами, надо дополнительно решать сколько именно их ставить, зачем это надо непонятно. Размер приятного отступа индивидуален, зависит от шрифта, как IDE их показывает, от размера экрана и вообще вкусовщина, где разумных доводов уже не найти. Кроме того, при клике мышкой четко в отступ не факт, что попадешь.
Поддерживаю, но как писали выше похоже просто так исторически получилось, но и пример с комментариями phpDoc тоже правильный
P.S. это из-за кармы я не могу ссылки в комментах ставить?
1) ссылка на слово «выше»: http://habrahabr.ru/post/266903/#comment_8573493
2) ссылка на слово «пример»: http://habrahabr.ru/post/266903/#comment_8573843
P.S. это из-за кармы я не могу ссылки в комментах ставить?
1) ссылка на слово «выше»: http://habrahabr.ru/post/266903/#comment_8573493
2) ссылка на слово «пример»: http://habrahabr.ru/post/266903/#comment_8573843
«Прочитав комментарии я полностью изменил свое мнение по поводу пробелов, проведя данное исследование хотелось разобраться в плюсах 4 пробелов перед табами, тем более тогда мне казалось, что у табов плюсов гораздо больше. Но теперь табы уже не кажутся такими хорошими как раньше. Да, нужно делать как в стандарте, тем более, что так делает большинство, зачем плыть против течения. Но у пробелов тоже есть свои минусы. В общем когда делали стандарт выбрали наименьшее зло из двух возможных (ИМХО).»
Не могли бы вы вкратце нписать в апдейте, чем собственно пробелы лучше? А то статья получается ущербной для читателя: всю статью доказываю что таб лучше, а в конце «не, вообще-то всё неправильно». Зачем тогда было тратить время читателя?
Хотеось бы на хабре читать взвешенные и ценные материалы, а не промежуточные и неверные результаты чьих-то исследований.
Не могли бы вы вкратце нписать в апдейте, чем собственно пробелы лучше? А то статья получается ущербной для читателя: всю статью доказываю что таб лучше, а в конце «не, вообще-то всё неправильно». Зачем тогда было тратить время читателя?
Хотеось бы на хабре читать взвешенные и ценные материалы, а не промежуточные и неверные результаты чьих-то исследований.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PSR-2, анализ одного пункта стандарта. Пробелы или табы