Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Всем похуй, пиши как удобно.
Предлагает, но не обязывает
php размягчает мозги, вот зенд и плющит.
Всегда «бесили» прибитые гвоздями стандарты кодинга.
Идеальный вариант — пайтон. Идеальный не просто тем что «их нет — нет проблем», а тем что таким образом сохраняется структурированность кода и он легче читается. Да и «стиль кодинга» «заставляет» его соблюдать.
В остальных языках придерживаюсь идей гугла и немного — GNU.
А стиль кода в проекте должен задавать главный кодер. Остальные обязаны его соблюдать.
Идеальный вариант — пайтон. Идеальный не просто тем что «их нет — нет проблем», а тем что таким образом сохраняется структурированность кода и он легче читается. Да и «стиль кодинга» «заставляет» его соблюдать.
В остальных языках придерживаюсь идей гугла и немного — GNU.
А стиль кода в проекте должен задавать главный кодер. Остальные обязаны его соблюдать.
Где я говорил о том: кто должен выбирать стиль?
«Остальные обязаны его соблюдать.»:
Ага, бездумно и беззаговорочно, и без обсуждений: как стадо баранов
«Остальные обязаны его соблюдать.»:
Ага, бездумно и беззаговорочно, и без обсуждений: как стадо баранов
Вы предлагаете бездумно, и без обсуждений, как стадо баранов писать хаотичный код?
Или бездумно, как стадо баранов, при каждом смене рабочего места доказывать что если делать один пробел там-то и там, то миру станет легче?
Все различия в стиле не так страшны, а соблюдение единого стиля очень сильно помогает.
Если стиль неправильно был выбрал с начала разработки, то ты не единственный будешь возмущаться.
Или бездумно, как стадо баранов, при каждом смене рабочего места доказывать что если делать один пробел там-то и там, то миру станет легче?
Все различия в стиле не так страшны, а соблюдение единого стиля очень сильно помогает.
Если стиль неправильно был выбрал с начала разработки, то ты не единственный будешь возмущаться.
Ну, у Питона из-за этого проблема с копипастом кода в веб.
«Ненужные» пробелы съедаются, и приходится весьма побиться, чтобы понять где начала и концы блоков
«Ненужные» пробелы съедаются, и приходится весьма побиться, чтобы понять где начала и концы блоков
Проблемы сегодняшних программистов в одном — они не знают в чём проблема и ищут её не там.
Это проблема не пайтона, а хайлайтера кода.
Многие хайлайтеры уже справляются с пайтоном на ура. Главное не миксуйте отступы в одном коде, а проще говоря: вставляйте валидный код(я намекаю на то что пайтон ругается на миксованные отступы).
Это проблема не пайтона, а хайлайтера кода.
Многие хайлайтеры уже справляются с пайтоном на ура. Главное не миксуйте отступы в одном коде, а проще говоря: вставляйте валидный код(я намекаю на то что пайтон ругается на миксованные отступы).
Во-первых если у вас 20 программистов и вы «главный» — составьте список требований к коду, который вам считается правильным, если нет — подайте эту здравую мысль «главному» и составьте этот список совместно с коллективом.
Во-вторых — можете написать(либо использовать готовое, если есть) что нибудь вроде Perl::Tidy (я из Perl комьюнити, пишу о том что знаю), для пост-обработки исходных кодов для приведения кода к общему стандарту (это не как отдельная мера, а в совокупности с первым моим пунктом)
Во-вторых — можете написать(либо использовать готовое, если есть) что нибудь вроде Perl::Tidy (я из Perl комьюнити, пишу о том что знаю), для пост-обработки исходных кодов для приведения кода к общему стандарту (это не как отдельная мера, а в совокупности с первым моим пунктом)
Где я говорил о том: кто должен выбирать стиль?
Вопрос в том: почему Вы выбираете именно такой стиль форматирования кавычек?
Вопрос в том: почему Вы выбираете именно такой стиль форматирования кавычек?
ааааа, потому что на одну строчку меньше => больше кода на экране имеющего смысловую нагрузку, ибо одиночная открывающая скобка на строку — глупость.
спасибо
и при этом коде снифер на соответствия стилям зенда пишет: 132 Line exceeds maximum limit of 120 characters; contains 122 characters
как-то не вяжется одно с другим
как-то не вяжется одно с другим
это уже интересно: есть ссылка на источник?
Ну 80, с получившими распространение широкоформатными мониками уже слишком мало, как мне кажется. Но ограничение на кол-во символов по ширине должно быть и это факт.
Вообще-то IDE могли бы уже давно научиться автоматически переносить строки, как это делают текстовые редакторы (ну почти).
Тогда я бы и в офисе на 19" мониторе и дома на 15" ноуте могу бы не париться длинной строк.
Тогда я бы и в офисе на 19" мониторе и дома на 15" ноуте могу бы не париться длинной строк.
# проверяем вменяемость компьютера
if ( 1 == 1 ) {
# всё в порядке
...
} else {
# что-то тут не так
...
}
В моём случае это совсем разные комментарии. «Внешний» — для всего блока if-else, «внутренние» — для конкретного условия.
В Вашем коде запутывает «внешний» комментарий, описывающий только один из внутренних блоков if-а и игнорирующий все остальные. Так перенесите его внутрь — он там будет к месту.
В Вашем коде запутывает «внешний» комментарий, описывающий только один из внутренних блоков if-а и игнорирующий все остальные. Так перенесите его внутрь — он там будет к месту.
У блока if-else уже есть комментарий. Если он не интересует, то пропускается полностью; интересует — с ним надо разбираться в любом случае. Однако чаще не интересует, и тут достаточно будет прочитать один общий комментарий, а не отследить все ветви if-а. Сами же условия в if в большинстве случаев в комментариях не нуждаются; слишком сложные лучше вынести в отдельные функции/методы и использовать затем самокомментирующий код if ( __check_if_this_or_that ) {...}
Стоит также отметить, что подобный стиль (открывающая скобка на новой строке) используется во многих PHP библиотеках и фрэймворках, включая symfony. И вот уж Sensio labs ну никак нельзя упрекнуть в том, что они принимают какие-то решения по накатанной, не обдумав.
Как по мне, так открывающая скобка на новой строке, действительно легче читается. А одно из основных предназначений кода — читаемость.
А сложности типа «на 41 символ больше, а PHP — не компилятор, а интерпритатор...» оставьте создателям языка. Если в документации написано, что интерпритатор игнорирует переносы строк и пробелы, значит он их игнорирует. Как? Это не ваша забота! Как только это становится вашей заботой — пора слазить на другой язык/компилятор/интерпритатор.
Как по мне, так открывающая скобка на новой строке, действительно легче читается. А одно из основных предназначений кода — читаемость.
А сложности типа «на 41 символ больше, а PHP — не компилятор, а интерпритатор...» оставьте создателям языка. Если в документации написано, что интерпритатор игнорирует переносы строк и пробелы, значит он их игнорирует. Как? Это не ваша забота! Как только это становится вашей заботой — пора слазить на другой язык/компилятор/интерпритатор.
Я после паскаля (в Delphi) никак не приучусь писать открывающую скобку (PHP) в той же строке. Просто лично для меня наглядней, когда я вижу, какая скобка к какой относится, особенно когда много вложений. Но при этом, меня не напрягают иные методы. Просто на фоне всех других проблем коллективной разработки это такая мелочь, которой можно пренебречь.
Проводил для себя эксперимент, в одном проекте с самого начала перемешивал оба этих стиля. Пришёл к выводу, что без переноса удобнее.
подобное уже обсуждалось:)
mrspd.habrahabr.ru/blog/82823/#comments
ru.wikipedia.org/wiki/Стиль_отступов
mrspd.habrahabr.ru/blog/82823/#comments
ru.wikipedia.org/wiki/Стиль_отступов
Нет никакой разницы в том, какой стиль вы выберете. Это просто холивар, не более того.
Главное:
1. Стандарт должен быть, любой, но должен быть.
2. Если вы пишете свой код на основе какой-то библиотеки (тот же ZF), то гораздо практичнее выбрать стиль и стандарты, соответствующие этой библиотеке. Тогда весь код — и ваш, и библиотеки будет всеми программистами читаться одинаково. Я надеюсь, не надо пояснять, что иногда приходится посмотреть и код библиотек?
Главное:
1. Стандарт должен быть, любой, но должен быть.
2. Если вы пишете свой код на основе какой-то библиотеки (тот же ZF), то гораздо практичнее выбрать стиль и стандарты, соответствующие этой библиотеке. Тогда весь код — и ваш, и библиотеки будет всеми программистами читаться одинаково. Я надеюсь, не надо пояснять, что иногда приходится посмотреть и код библиотек?
У Ruby, кстати, есть и запись блоков вида
Но рекомендуется её использовать только для однострочных блоков.
Кроме того, такая запись — не синоним для
['a','b','c'].each {|s| p s}Но рекомендуется её использовать только для однострочных блоков.
Кроме того, такая запись — не синоним для
do...end, у них разные приоритеты. (см. www.ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/syntax.html#iter )
> Сегодня я разделю вас простой вещью на два лагеря
Какая дикая наивность. Уже лет пятьдесят как делят и делят, и конца и края не видно.
А дальше у вас в разделах «Что предлагает» бредятина написана. Никто никому ничего не предлагает, кроме питона, где нет выбора.
Какая дикая наивность. Уже лет пятьдесят как делят и делят, и конца и края не видно.
А дальше у вас в разделах «Что предлагает» бредятина написана. Никто никому ничего не предлагает, кроме питона, где нет выбора.
Отвечая на вопрос автора:
В большинстве случаев я переношу "{" на новую строку, ибо начало и конец блока лучше видно, когда они на одном уровне.
Исключение здесь — else. Его я пишу так: "} else {". Потому что три строки для одного else — это слишком.
Комментарии расставляю так:
if(cond) // Коммент если тру
{
...code…
} else { // Коммент обратной ситуации
...code…
}
Когда внутри блока мало кода, стараюсь «свернуть» блок — весь блок в одну строку вместе с тем, что было перед блоком. Т.е. так: «if (isTrue) {o.someMethod();}».
Не сворачиваю только try..catch — ещё не знаю, почему.
Ещё я люблю писать длинные строки и переношу их так, чтобы знаки соединения строк были в начале новой строки, в не в конце старой, ибо так лучше видно, что это продолжение строки, а не новая строка:
Perl:
$q.=«blah blah blah».someSub().«blah blah»
.someSub();
Java:
q=«blah blah blah»+someSub()+«blah blah»
+someSub();
o.someMethod(param1, param2).someMethod2(p)
.someMethod3();
А ещё я не гнушаюсь делать несколько return'ов по ходу выполнения функции.
Если соблюдать правило о том, что функции должны быть маленькими и выполнять маленькие задачи, это не становится проблемой.
А ещё я использую отступы в виде символов табуляции и выставляю их размер в 4 символа =)
В большинстве случаев я переношу "{" на новую строку, ибо начало и конец блока лучше видно, когда они на одном уровне.
Исключение здесь — else. Его я пишу так: "} else {". Потому что три строки для одного else — это слишком.
Комментарии расставляю так:
if(cond) // Коммент если тру
{
...code…
} else { // Коммент обратной ситуации
...code…
}
Когда внутри блока мало кода, стараюсь «свернуть» блок — весь блок в одну строку вместе с тем, что было перед блоком. Т.е. так: «if (isTrue) {o.someMethod();}».
Не сворачиваю только try..catch — ещё не знаю, почему.
Ещё я люблю писать длинные строки и переношу их так, чтобы знаки соединения строк были в начале новой строки, в не в конце старой, ибо так лучше видно, что это продолжение строки, а не новая строка:
Perl:
$q.=«blah blah blah».someSub().«blah blah»
.someSub();
Java:
q=«blah blah blah»+someSub()+«blah blah»
+someSub();
o.someMethod(param1, param2).someMethod2(p)
.someMethod3();
А ещё я не гнушаюсь делать несколько return'ов по ходу выполнения функции.
Если соблюдать правило о том, что функции должны быть маленькими и выполнять маленькие задачи, это не становится проблемой.
А ещё я использую отступы в виде символов табуляции и выставляю их размер в 4 символа =)
Автор, а ты давно то php видел? Раз предлагаешь нам лишние строчки удалять ради производительности? Может еще как JS сжимать его? Зашел бы хотя бы на php.net, почитал что там и как, прежде чем писать что-то подобное.
Никогда не переношу открывающую скобку. Привычка пошли из других языков, где может быть создан просто блок кода (не помню как такое называется) в любом месте:
method_declaration() {
…
{
…
}
…
}
Кроме того, на эту тему хорошо написал Макконнелл.
method_declaration() {
…
{
…
}
…
}
Кроме того, на эту тему хорошо написал Макконнелл.
Сколько пафоса в первом же абзаце. Если вы не можете с чем-то согласиться, это не значит, что другие соглашаются с этим потому, что они глупы.
Каждый программист/фирма устанавливают для себя свои стандарты кодирования, которые удобны им, а не кому-то другому. Если это совпало с тем, что вам не нравится, значит эти люди глупы и идут на поводу? Вы наивны.
Про себя могу сказать, что всегда делал перенос открывающей скобки, потому что мне так легче воспринимать код. Навязывать этот стиль кому-то — зачем?
И последнее. Автор же не забыл, что PHP — интерпрЕтатор?
Каждый программист/фирма устанавливают для себя свои стандарты кодирования, которые удобны им, а не кому-то другому. Если это совпало с тем, что вам не нравится, значит эти люди глупы и идут на поводу? Вы наивны.
Про себя могу сказать, что всегда делал перенос открывающей скобки, потому что мне так легче воспринимать код. Навязывать этот стиль кому-то — зачем?
И последнее. Автор же не забыл, что PHP — интерпрЕтатор?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хотите «holy war» — получайте: curly braces