Этот документ предоставляет указания по форматированию кода и документированию для разработчиков и команд, работающих с Zend Framework'ом. Многие разработчики, использующие Zend Framework, также находят эти указания полезными, так как стиль их кода остается единообразным со всем кодом Zend Framework. Так же, стоит заметить, что требуются значительные усилия для полного определения стандартов кодирования. Иногда разработчики считают само введение стандарта более важным, нежели то, что именно конкретный стандарт предполагает на более детальном уровне. В Стандарте кодирования Zend Framework'а описываются приемы и практики, которые хорошо зарекомендовали себя для проекта Zend Framework. Вы можете модифицировать этот стандарт или использовать как есть, в соответствии с условиями нашей лицензии. Освещаемые темы в Стандарте кодирования Zend Framework'а включают: Форматирование PHP-файлов Соглашения по именованию Стиль кодирования Встроенная документация Хороший стандарт кодирования важен в любом проекте, и особенно там, где множество разработчиков работают над одним проектом. Наличие стандарта кодирования помогает гарантировать, что код - высокого качества, с меньшим количеством ошибок и легко поддерживается. Для файлов, содержащих только PHP-код, закрывающий тег ("?>") не разрешен. Он не требуется синтаксисом PHP и его пропуск предотвращает случайное включение в вывод конечных пробелов. ВАЖНО: Включение бинарных файлов, как разрешает __HALT_COMPILER(), запрещено из любого PHP-файла Zend Framework'а или файлов производных от него. Эта возможность разрешена для использования только в специальных инсталляционных скриптах. Для отступа используйте 4 пробела. Не используйте символ табуляции. Рекомендуемая длина строки составляет 80 символов, т.е. разработчики должны стремиться держать код как можно ближе к 80-символьной границе, когда это возможно. Однако более длинные строки также допустимы. Максимальная длина любой строки PHP-кода не должна превышать 120 символов. Переводы строк должны быть как принято для текстовых файлов в Unix-системах. Строки должны заканчиваться только символом перевода на новую строку (LF). Символ перевода на новую строку в десятичном виде представляется как число 10, или как 0x0A в шестнадцатеричном. Не используйте комбинацию символов возврата каретки/перевода строки (CRLF) как на Windows-компьютерах (0x0D, 0x0A). Zend Framework использует схему именования классов, в соответствии с которой имена классов напрямую указывают на директории, где они находятся. Корневой директорией стандартной библиотеки Zend Framework'а является директория "Zend/", а дополнительной - директория "ZendX/". Все классы Zend Framework расположены иерархически в этих корневых директориях. Имена классов могут содержать только буквенно-числовые символы. Числа допустимы в именах классов, но не приветствуются. Символы нижнего подчеркивания допустимы в местах разделителей пути - имя файла "Zend/Db/Table.php" должно указывать на класс с именем "Zend_Db_Table". Если имя класса состоит из более чем одного слова, то первая буква каждого слова должна быть заглавной. Последующие заглавные буквы недопустимы, например, имя класса "Zend_PDF" - недопустимо, в то время как "Zend_Pdf" - допустимо. Эти соглашения определяют механизм псевдо-нэймспэйсов для Zend Framework. Zend Framework будет использовать функционал PHP нэймспэйсов, когда он станет доступен и применим для разработчиков для использования в их приложениях. Смотри имена классов в стандартной и дополнительной библиотеках в качестве примера этой схемы именования. ВАЖНО: Код, который должен использоваться вместе с Zend Framework, но не являющийся частью стандартной либо дополнительной библиотек (тоесть код приложения или библиотеки, распространяемый не компанией Zend), не должен начинаться с префиксов "Zend_" или "ZendX_" . В основном, абстрактные классы следуют тем же соглашениям, что и классы, с одним дополнительным правилом: имена абстрактных классов должны заканчиваться словом "Abstract" и перед ним не должно быть нижнего подчеркивания. Как пример, Zend_Controller_Plugin_Abstract считается неправильным, в то время как Zend_Controller_PluginAbstract или Zend_Controller_Plugin_PluginAbstract - правильны. Эта схема именования появилась с версии 1.9.0 Zend Framework'a. Классы, предшествующие этой версии могут не следовать данному правилу, но в будущем будут переименованы для соответствия. Логическое обоснование этому изменению связано с использованием нэймспэйсов. Планируя переход к Zend Framework 2.0 и использование PHP 5.3, мы готовимся использовать нэймспэйсы. Простейший способ автоматизировать переход к нэймспэйсам - это просто преобразовать нижнее подчеркивание в разделитель нэймспэйса, но в случае старой схемы именования это сделает итоговым именем классов просто "Abstract" или "Interface", которые являются зарезервированными ключевыми словами в PHP. Если же мы добавим имя (суб)компонента к имени класса, то сможем избежать этих проблем. Для демонстрации ситуации, представьте преобразование класса Zend_Controller_Request_Abstract для использования нэймспэйсов: Очевидно, это не сработает. Но с новой схемой именования это будет выглядеть так: Мы сохраняем семантику и разделением нэймспэйсами, в тоже время мы избегаем проблем с ключевыми словами. Так же, так лучше описывается абстрактный класс. В основном, интерфейсы следуют тем же соглашениям, что и классы, с одним дополнительным правилом: имена интерфейсов должны заканчиваться словом "Interface" и перед ним не должно быть нижнего подчеркивания. Как пример, Zend_Controller_Plugin_Interface считается неправильным, в то время как Zend_Controller_PluginInterface или Zend_Controller_Plugin_PluginInterface - правильны. Хотя это правило не считается обязательным, оно настоятельно рекомендуется, так как предоставляет разработчикам хороший визуальный ключ к пониманию, какие файлы содержат интерфейсы, а не классы. Эта схема именования появилась с версии 1.9.0 Zend Framework'a. Интерфейсы, предшествующие этой версии могут не следовать данному правилу, но в будущем будут переименованы для соответствия. Смотри предыдущую секцию для дополнительной информации по логическому обоснованию этого изменения Для файлов допустимы буквенно-числовые символы, символы нижнего подчеркивания и тире ("-"). Пробелы запрещены. Любой файл содержащий PHP-код должен иметь расширение ".php", за исключением скриптов вида. Это примеры показывают допустимые имена файлов для классов из примеров в секции выше: Имена файлов отражаются на имена классов, как описано выше. Имена функций могут содержать буквенно-числовые символы. Символы нижнего подчеркивания не разрешены. Числа разрешены в именах функций, но не приветствуются. Имена функций должны всегда начинаться с буквы в нижнем регистре. Когда имя функции состоит из более чем одного слова, первая буква каждого нового слова должна быть заглавной. Это обычно называется "верблюжьей(camelCase)" нотацией. Многословность приветствуется. Имена функций должны быть настолько говорящими, насколько это практично для повышения понимаемости кода. Это примеры допустимых имен функций: Для объектно-ориентированного программирования принято, чтобы методы доступа имели префикс "get" или "set". Когда используются шаблоны проектирования, такие, как "синглтон" или "фабрика", где возможно, имена методов должны содержать имя шаблона, чтобы можно было быстро узнать шаблон. Для методов, объявленных с помощью префиксов области видимости "private" или "protected", первый символ имени должен быть нижним подчеркиванием. Это единственное допустимое применение нижнего подчеркивания в имени метода. Методы объявленные как "public" никогда не должны иметь нижнего подчеркивания в имени. Функции в глобальной области видимости ("плавающие функции") допустимы, но не приветствуются. Рекомендуется обрамлять такие функции в статические классы. Имена переменных могут содержать буквенно-числовые символы. Символы нижнего подчеркивания не разрешены. Числа разрешены в именах переменных, но не приветствуются. Для переменных - членов классов, определенных с помощью префиксов области видимости "private" или "protected", первый символ имени должен быть символом нижнего подчеркивания. Это единственное допустимое использование символа нижнего подчеркивания в имени. Переменные - члены классов определенные с помощью префикса области видимости "public" никогда не должны начинаться с символа нижнего подчеркивания. Как и имена функций (смотри секцию 3.3), имена переменных должны начинаться с буквы в нижнем регистре и следовать "верблюжьей" нотации. Многословность приветствуется. Имена переменных должны быть настолько говорящими, насколько это практично. Краткие имена переменных, такие как "$i" и "$n" не приветствуются нигде, кроме как в контексте маленьких циклов. Если цикл содержит более 20 строк кода, то переменные для индексов должны иметь более говорящие имена. Константы могут содержать буквенно-числовые символы, символы нижнего подчеркивания. Числа в именах констант разрешены. Имена констант должны быть в верхнем регистре, слова в имени должны быть разделены нижним подчеркиванием. Например, EMBED_SUPPRESS_EMBED_EXCEPTION разрешены, а EMBED_SUPPRESSEMBEDEXCEPTION - нет. Константы должны быть определены как члены классов с использованием ключевого слова "const". Определение констант в глобальной области видимости с помощью "define" допустимо, но не рекомендуется. PHP-код должен всегда обрамляться полными PHP-тегами: ]]> Короткие теги не допустимы. В файлах, содержащих только PHP-код, закрывающий так должен быть опущен. (Смотри Общие стандарты). Когда строка является литеральной (не содержит подстановок переменных), для ее обрамления должны использоваться апострофы или "одинарные кавычки": Когда строка литералов сама содержит апострофы, разрешается для обрамления строки использовать "двойные кавычки". Это особенно актуально для SQL-запросов: Синтаксис выше является более предпочтительным, чем экранирование апострофов. Подстановка переменных разрешается с использованием нижеприведенных форм: Для надежности, эта форма не допустима: Строки должны объединятся с помощью оператора ".". Пробел должен всегда добавляться до и после оператора "." для улучшения читабельности: Когда производится конкатенация строк с помощью оператора ".", разрешается разрывать выражение на несколько строк для улучшения читабельности. В этом случае, каждая следующая строка должна быть дополнена пробелами так, чтобы оператор "." был выровнен под оператором "=": Отрицательные числа в качестве индексов запрещены. Хотя индекс массива может начинаться с любого неотрицательного числа, но не приветствуется и не рекомендуется начинать индексирование не с 0. Когда определяется индексированный массив с помощью конструкции Array, завершающий пробел должен быть добавлен после каждой запятой для улучшения читабельности: Также разрешается определять многострочные индексированные массивы, используя конструкцию "array". В этом случае, каждая следующая строка должна быть дополнена пробелами так, чтобы начало каждой строки было выравнено как показано ниже: В качестве альтернативы, начальный элемент может располагаться на следующей строке. В этом случае он должен быть сдвинут на один уровень отступа больше, чем строка содержащая объявление массива. Все последующие строки должны иметь аналогичный отступ. Закрывающая скобка должна быть на отдельной строке с уровнем отступа, что и строка, содержащая объявление массива: При использовании последнего способа мы рекомендуем ставить запятую после последнего элемента массива. Это упрощает добавление новых строк и обеспечивает отсутствие ошибок из-за пропущенной запятой. Когда определяется ассоциативный массив с помощью конструкции Array, приветствуется разделение выражения на несколько строк. В этом случае, каждая следующая строка должна быть дополнена с помощью пробелов так, чтобы и ключи и значения были выровнены: 'firstValue', 'secondKey' => 'secondValue'); ]]> В качестве альтернативы, начальный элемент может располагаться на следующей строке. В этом случае он должен быть сдвинут на один уровень отступа больше, чем строка содержащая объявление массива. Все последующие строки должны иметь аналогичный отступ. Закрывающая скобка должна быть на отдельной строке с уровнем отступа, что и строка, содержащая объявление массива. Для удобочитаемости, "=>" должен быть выравнен пробелами относительно остальных: 'firstValue', 'secondKey' => 'secondValue', ); ]]> При использовании последнего способа мы рекомендуем ставить запятую после последнего элемента массива. Это упрощает добавление новых строк и обеспечивает отсутствие ошибок из-за пропущенной запятой. Классы должны быть именованы согласно схеме именования Zend Framework. Фигурная скобка всегда пишется на следующей строке под именем класса. Каждый класс должен иметь блок документации (doc-блок) в соответствии со стандартом PHPDocumentor. Код внутри класса должен иметь отступ в четыре пробела. Только один класс разрешен внутри одного PHP-файла. Размещение дополнительно кода в файле с классом разрешено, но не приветствуется. В таких файлах, две пустые строки должны разделять класс и дополнительный PHP-код. Это пример допустимого определения класса: Классы, расширяющие другие классы или реализующие интерфейсы, должны объявлять свои зависимости на той же строке, если возможно. Если в результате такого объявления, длина строки превышает максимальную длину строки, сделайте перенос перед ключевыми словами "extends" и/или "implements" и сделайте отступ в один уровень. Если класс реализует несколько интерфейсов и объявление превышает максимальную длину строки - сделайте перенос после запятой, разделяющей интерфейсы, и выровняйте их имена пробелами: Переменные-члены классов должны быть именованы согласно схеме именования Zend Framework. Любые переменные, определенные в классе, должны быть определены в начале класса, до определения любого метода. Ключевое слово var не разрешено. Члены класса должны всегда определять их область видимости, используя ключевое слово private, protected или public. К публичным переменным-членам класса доступ напрямую разрешен, но не приветствуется в пользу методов доступа (set & get). Функции должны должны быть именованы согласно схеме именования Zend Framework. Функции внутри классов должны всегда определять свою область видимости с помощью одного из префиксов private, protected или public. Как и у классов, фигурная скобка всегда пишется на следующей строке под именем функции. Пробелы между именем функции и круглой скобкой для аргументов не допускаются. Функции в глобальной области видимости крайне не приветствуются. Это пример допустимого определения функции: В случае, если список аргументов превышает максимальную длину строки, можно делать перенос строки. Аргументы, перенесенные на следующую строку, должны иметь отступ на один уровень больше чем у объявления метода или функции. Закрывающая скобка должна быть на новой строке с отступом, как у объявления функции/метода, а после нее, через пробел, должна находиться открывающая фигурная скобка. Ниже приведен пример такой ситуации: Передача по ссылке допустима только в определениях функций: Передача по ссылке во время вызова строго запрещена. Возвращаемое значение не должно обрамляться в круглые скобки, иначе это ухудшает читабельность, а также может нарушить код, если метод позже станет возвращать результат по ссылке. bar); } /** * ХОРОШО */ public function bar() { return $this->bar; } } ]]> Аргументы функции разделяются одним завершающим пробелом после каждой запятой. Это пример допустимого вызова функции для функции, которая принимает три аргумента: Передача по ссылке во время вызова запрещена. Смотрите секцию определения функций для правильного способа передачи аргументов функции по ссылке. Для функций, чьи аргументы допускают массив, вызов функции может включать конструкцию "array" и может быть разделено на несколько строк для улучшения читабельности. В этом случае, применим стандарт описания массивов: Управляющие структуры, основанные на конструкциях if и elseif, должны иметь один пробел до открывающей круглой скобки условия, и один пробел после закрывающей круглой скобки. Внутри выражения условия между круглыми скобками операторы должны разделяться пробелами для читабельности. Внутренние скобки приветствуются для улучшения логической группировки больших условий. Открывающаяся фигурная скобка пишется на той же строке, что и условие. Закрывающаяся фигурная скобка пишется на отдельной строке. Все содержимое между скобками пишется с отступом в четыре пробела. Если условное выражение заставляет строку превысить максимальную длину строки и имеет несколько условий, вы можете разбить его на несколько строк. В таком случае, делайте перенос до логического оператора и выравнивайте пробелами до первого символа условного выражения. Закрывающая скобка должна быть на новой строке, с уровнем отступа как у управляющей структуры. На той же строке, через пробел, должна находиться открывающая фигурная скобка. Цель последнего формата - предотвратить сложности, при добавлении или удалении условий из условного выражения в последующих изменениях. Для выражения "if", включающего "elseif" или "else", форматирование должно быть таким, как в следующем примере: PHP допускает написание таких выражений без фигурных скобок при некоторых условиях. Стандарт кодирования не делает различий - для всех "if", "elseif" или "else" выражений необходимо использовать фигурные скобки. Управляющие структуры, написанные с использованием "switch" конструкции, должны иметь один пробел до открывающей круглой скобки условного выражения, и также один пробел после закрывающей круглой скобки. Все содержимое между фигурными скобками пишется с отступом в четыре пробела. Содержимое каждого "case" выражения должно писаться с отступом в дополнительные четыре пробела. Ключевое слово default никогда не должно опускаться в выражении switch. Иногда полезно писать case выражения, которые передают управление следующему case выражению, опуская break или return. Для того, чтобы отличать такие случаи от ошибок, каждое case выражение, где опущен break или return, должно содержать комментарий, указывающий, что это сделано преднамеренно. Все блоки документации ("doc-блоки") должны быть совместимы с форматом phpDocumentor. Описание формата phpDocumentor вне рамок данного докумета. Для дополнительно информации смотрите: http://phpdoc.org/ Все файлы с классами должны содержать doc-блок "уровня файла" и непосредственно перед каждым классом doc-блок "уровня класса". Примеры таких doc-блоков можно увидеть ниже. Каждый файл, содержащий PHP-код должен иметь заголовочный doc-блок в начале файла, содержащий как минимум следующие phpDocumentor-теги(для Zend Framework): Тэг @category должен иметь значение "Zend". Тэг @package должен быть, и иметь значение, соответствующее имени компонента, к которому принадлежит класс. Обычно, имеет только два сегмента: префикс "Zend" и имя компонента. Тэг @subpackage необязателен. Если предоставлен, должен быть именем подкомпонента минус префикс класса. В примере выше, предполагается, что класс в файле или "Zend_Magic_Wand", или использует это имя в качестве части части префикса. Каждый класс должен иметь doc-блок, содержащий как минимум следующие phpDocumentor-теги: Тэг @category должен иметь значение "Zend". Тэг @package должен быть, и иметь значение, соответствующее имени компонента, к которому принадлежит класс. Обычно, имеет только два сегмента: префикс "Zend" и имя компонента. Тэг @subpackage необязателен. Если предоставлен, должен быть именем подкомпонента минус префикс класса. В примере выше, предполагается, что класс в файле или "Zend_Magic_Wand", или использует это имя в качестве части части префикса. Каждая функция, включая методы объектов, должна иметь doc-блок, содержащий как минимум: Описание функции Все аргументы Все возможные возвращаемые значения Нет надобности использовать тег "@access", потому что область видимости уже известна из ключевых слов "public", "private" или "protected". используемых при определении функции. Если функция/метод может выбрасывать исключение, используйте тег @throws: