Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Zend Framework Coding Standard for PHP
PEAR Coding Standards
Horde Coding Standards
Опрос предложен хабраюзером vooD, у которого для него не хватило кармы. Плюсы можно ставить ему, минусы — мне.
PEAR Coding Standards
Horde Coding Standards
Опрос предложен хабраюзером vooD, у которого для него не хватило кармы. Плюсы можно ставить ему, минусы — мне.
Должен быть пункт «В зависимости от проекта».
В пхп очень часто приходиться иметь дело с проектами которые скажем так легаси. В итоге в разных проектах разные нотации и разные степени отсутствия оной.
В пхп очень часто приходиться иметь дело с проектами которые скажем так легаси. В итоге в разных проектах разные нотации и разные степени отсутствия оной.
в основе Вашего стиля кодирования лежит быдлокод T_T
Т.к. я пишу в основном на symfony, то и использую их стандарты. Хотя часто возникают проблемы, когда, например, использую библиотеки из Zend или другого проекта в котором стиль кодирования отличается и нужно расширить функционал (например унаследоваться от класса), то встает вопрос в каком стиле этот новый класс писать :)
Когда занимаюсь реализацией обособленных проектов, то использую свой стиль (помесь PEAR+Zend, почти как в Kohana).
Но когда нужно сделать модуль — стараюсь максимально соответствовать стандартам кодирования проекта.
Думаю это лучший подход, т.к сложно использовать модули/хаки/подсистемы написанные без понимания стандарта кодирования конкретного проекта.
Но когда нужно сделать модуль — стараюсь максимально соответствовать стандартам кодирования проекта.
Думаю это лучший подход, т.к сложно использовать модули/хаки/подсистемы написанные без понимания стандарта кодирования конкретного проекта.
Drupal coding standards
Zend. Но использую табы вместо пробелов. Пробовал кодить пробелами, но это слишком сложно. Кстати, даже в ZF кривые отступы из-за того что используются пробелы.
Вот интересно, сколько % кодеров используют пробелы и сколько табы?
Вот интересно, сколько % кодеров используют пробелы и сколько табы?
У меня выработался свой собственный стиль, который, как выяснилось, очень очень похож на Zend :)
Думал, что использую свой стиль, но пройдясь по ссылкам, понял что это не так.
Оказывается этот стиль называется Horde, он легко читается и понимается, стараюсь делать, чтобы разработчикам после меня было нетрудно разобраться.
Оказывается этот стиль называется Horde, он легко читается и понимается, стараюсь делать, чтобы разработчикам после меня было нетрудно разобраться.
Использую тот стиль, который используется в том инструменте, с помощью которого решается задача. Yii — стиль Yii, ZF — значит стиль ZF.
Сейчас ближе всего к Doctrine.
А вообще Pear, ZF, Symfony, Doctrine очень похожи и отличаются только в мелочах.
А вообще Pear, ZF, Symfony, Doctrine очень похожи и отличаются только в мелочах.
Я использую отступ из трёх пробелов (не четырёх) и нередко воздерживаюсь от фигурных скобок вокруг однострочных if, а также воздерживаюсь от круглых скобок вокруг простых аргументов логических операторов, но в остальном мой код зендоподобен.
Стандарт PEAR вызывает у меня ужас требованием переносить длинные строки, начиная с оператора, а не оставлять оператор в конце предыдущей строки. Я же пишу иногда и на джаваскрипте, а там этакий код имеет все шансы нарваться на автоподстановку «;» интерпретатором. Также мне кажется неприемлемою (неэкономною) манера PEAR и Horde переносить «{» на следующую строку в нескольких случаях. Также не очень понятно, зачем перевод строки после последнего «?>».
Я, однако, следую стандартам PEAR в части воздержания от «#», считаю разумным употребление «_once» (хотя сам иногда забываю), всегда использую «<?php» вместо «<?» (и ненавижу код, в котором это правило не соблюдается), стараюсь прибегать к быстрому простому return.
Докблоки сочинять ещё не выучился — может быть, вон то простое пособие станет простой отправной точкою.
Я следую рекомендуемой Horde оптимизации, используя «.» для стыковки строк и переменных вместо того, чтобы записывать имена переменных внутри строки, обрамлённой «"». (За исключением периодов клавиатурной лени.)
Стандарт PEAR вызывает у меня ужас требованием переносить длинные строки, начиная с оператора, а не оставлять оператор в конце предыдущей строки. Я же пишу иногда и на джаваскрипте, а там этакий код имеет все шансы нарваться на автоподстановку «;» интерпретатором. Также мне кажется неприемлемою (неэкономною) манера PEAR и Horde переносить «{» на следующую строку в нескольких случаях. Также не очень понятно, зачем перевод строки после последнего «?>».
Я, однако, следую стандартам PEAR в части воздержания от «#», считаю разумным употребление «_once» (хотя сам иногда забываю), всегда использую «<?php» вместо «<?» (и ненавижу код, в котором это правило не соблюдается), стараюсь прибегать к быстрому простому return.
Докблоки сочинять ещё не выучился — может быть, вон то простое пособие станет простой отправной точкою.
Я следую рекомендуемой Horde оптимизации, используя «.» для стыковки строк и переменных вместо того, чтобы записывать имена переменных внутри строки, обрамлённой «"». (За исключением периодов клавиатурной лени.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если Вы программируете на PHP, в основе Вашего стиля кодирования лежит