Существует ли устоявшееся соглашение об именах для пространств имен PHP? - PullRequest
32 голосов
/ 30 ноября 2009

До сих пор я видел много разных соглашений об именах, используемых для пространств имен PHP. Некоторые люди используют PascalCase\Just\Like\For\Classes, некоторые используют underscored\lower_case\names, некоторые даже используют соглашение Java для имен пакетов: com\domain\project\package.

Вопрос очень прост - можно ли назвать любое из этих (или других) соглашений общепризнанным? Зачем? Рекомендуются ли какие-либо из них такими авторитетами, как Zend или разработчиками известных PHP-фреймворков?

Ответы [ 3 ]

26 голосов
/ 14 сентября 2010

Рабочая группа по стандартам PHP, состоящая из участников различных PHP-фреймворков и проектов, предложила следующее предложение для соответствующего использования пространства имен:

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

5 голосов
/ 30 ноября 2009

Я не думаю, что вы можете сказать, что на данный момент что-то хорошо установлено, но есть RFC, обсуждающий это для PEAR2: http://wiki.php.net/pear/rfc/pear2_naming_standards

Я предполагаю, что пространства имен являются формой переменных и поэтому должны следовать тем же правилам, что и они. Обычно я предпочитаю lowercase_underscore для свободных переменных (в отличие от членов объекта), поэтому наиболее естественным на мой вкус будет namespace\ClassName. Это также соответствует наиболее распространенным соглашениям из других языков. С другой стороны, тот же аргумент может быть приведен для псевдо-пространств до 5.3, но здесь стандарт де-факто, похоже, использует CamelCase.

1 голос
/ 30 ноября 2009

Лично мне нравится писать имена классов в верхнем регистре, атрибуты и методы классов в нижнем регистре и атрибуты класса с префиксом подчеркивания.

Другие локальные переменные Я также пишу нижний регистр верблюдов без префикса подчеркивания. Экземпляры объектов всегда пишутся как верхний верблюд и т. Д. И т. Д. Я действительно не думаю, что есть лучший способ, вы просто должны соответствовать вашему стандарту кодирования. Это дает вам преимущество, заключающееся в более быстром чтении вашего кода, и это должно дать более быстрое понимание того, что происходит с какими строками кода.

...