Разработчики CodeIgniter вводят правила оформления кода

Владимир | | CodeIgniter, PHP, Web разработка.

coding standards

В документации к новой версии CodeIgniter 1.7 появился новый раздел General Style and Syntax (Общий стиль и синтаксис). В нем описаны рекомендации по оформлению кода при разработке с использованием CodeIgniter.

Релиз этой версии фреймворка еще не вышел. Поэтому скачать ее можно только из репозитория Subversion по адресу (http://dev.ellislab.com/svn/CodeIgniter/trunk/). А страница документации с рекомендациями находится здесь.

Пересказывать их все нет смысла. Большую часть этих правил и так все соблюдают. Но вот некоторые – довольно интересны. О них я и расскажу.

Имена классов и методов

Имена классов должны начинаться с большой буквы, все остальные буквы – маленькие. Разделитель между словами – символ «_». Примеры.

НЕПРАВИЛЬНО:
class superclass
class SuperClass

ПРАВИЛЬНО:
class Super_class

Честно говоря, я привык ко второму неправильному 😉 варианту (т.н. CamelCased). Естественно, уже существующий код переделывать не придется. И, честно говоря, URL с подчеркиваниями мне не очень нравятся.

Имена методов составляются по тому же принципу, только первая буква маленькая.

Закрывающий PHP тег

Вместо ?> нужно использовать конструкцию

/* End of file myfile.php */
/* Location: ./system/modules/mymodule/myfile.php */

Это правило больше относится к PHP чем к CodeIgniter. Дело в том, что закрывающий тег не является обязательным. Но, если вы его используете и после него случайно поставите пробел, то этот пробел будет отправлен браузеру. В большинстве случаев это не страшно, но, например, установить заголовки (headers) вы уже не сможете.

TRUE, FALSE, и NULL – всегда большими буквами. Еще одно правило, которое я редко соблюдаю.

Логические операторы

Вот тут можно запутаться. Вместо || нужно использовать OR, но && предпочтительнее AND. Причина — || выглядит похоже на 11.

Операторы сравнения

Всегда нужно проверять тип сравниваемый переменных. Т.е. использовать === вместо ==.

Тут я полностью поддерживаю разработчиков. В PHP нет строгой типизации переменных, как, например, в C++, из-за этого могут возникнуть ошибки, которые будет сложно найти.

Пробельные символы в файлах

Их не должно быть перед открывающими и закрывающими PHP тегами. Интересный момент. В оригинале написано:

ExpressionEngine output is buffered, so….
(Вывод ExpressionEngine буферизируется, поэтому…)

ExpressionEngine – это CMS, которую разрабатывает EllisLab. Они же разработчики и CodeIgniter. Сразу виден первоисточник 😉 .

Использование $SESS->cache

Этот многомерный массив позволяет исключить выполнения одного и того же кода при создании страницы. Массив всегда должен быть многомерным, чтобы исключить одновременное использование одних и тех же элементов в вашем коде и сторонних библиотеках. Т.е. $SESS->cache['admins'] использовать нельзя.

Пример:

if ( ! isset($SESS->cache['super_class']['admins'])) {
	$query = $DB->query("SELECT member_id FROM exp_super_class_admins");
	if ($query->num_rows > 0) {
		foreach ($query->result as $row) {
			$SESS->cache['super_class']['admins'][] = $row['member_id'];
		}
	}
}
// установка локальной переменной из глобального кеша
$admins = $SESS->cache['super_class']['admins'];

Широко распространенные слова

К ним нужно добавлять приставку. Желательно уникальную. Что-то вроде:
sc_email
sc_xml

Имена таблиц в БД

Еще одно непонятное требование. Разработчики предлагают использовать две приставки. Первая «exp_» и вторая, которая как-то связана с вами или компанией, которую вы представляете.

Т.е. выглядеть названия таблиц будут примерно так:
exp_simplecoding_email_addresses

При этом авторы документации напоминают, что MySQL имеет ограничение на длину имени таблицы в 64 символа.

По-моему, это перебор. Вполне логично, когда таблицы имеют приставку, которую можно изменять. Например, можно использовать одну базу данных для нескольких дистрибутивов WordPress, если установить разные приставки для таблиц. Но две приставки, одна из которых постоянная… Этого я не понимаю.

Переносы строк

Должны соответствовать Unix стандарту. Этот пункт касается в основном пользователей Windows. Вывод простой. Notepad для редактирования файлов CodeIgniter теперь не подходит, нужно использовать более «продвинутый» редактор.

Строки

Всегда используйте одиночные кавычки, если в строке не используется парсинг переменных или другие одиночные кавычки. Например.

НЕПРАВИЛЬНО:
"My String"
"My string $foo"
'SELECT foo FROM bar WHERE baz = \'bag\''

ПРАВИЛЬНО:
'My String'
"My string {$foo}"
"SELECT foo FROM bar WHERE baz = 'bag'"

Как видите, правила довольно простые.

А что вы думаете об использовании стандартов оформления кода?

  • А мне все таки больше Kohana понравилась, производная CodeIgniter

  • А мне все таки больше Kohana понравилась, производная CodeIgniter

  • В моём отделе придерживаются стандартов кодирования от Zend'a (http://framework.zend.com/manual/en/coding-standard.html), т.к. во первых они схожи с PEAR (к которому одно время стремились), а во вторых пишем проекты под ZF 🙂

  • В моём отделе придерживаются стандартов кодирования от Zend'a (http://framework.zend.com/manual/en/coding-standard.html), т.к. во первых они схожи с PEAR (к которому одно время стремились), а во вторых пишем проекты под ZF 🙂

  • MAX

    Ну хорошо хоть не заставляют всех одним редактором/средой разработки пользоваться. 😉

    • Этих правил тоже никто не заставляет придерживаться 😉

  • MAX

    Ну хорошо хоть не заставляют всех одним редактором/средой разработки пользоваться. 😉

    • Этих правил тоже никто не заставляет придерживаться 😉

  • Sam

    Все эти правила из мануала EE перекочевали.

    • Хороший, кстати, метод. Не нравятся существующие стандарты. Создаем собственный фреймворк или библиотеку и пишем новые стандарты 😉 .

  • Sam

    Все эти правила из мануала EE перекочевали.

    • Хороший, кстати, метод. Не нравятся существующие стандарты. Создаем собственный фреймворк или библиотеку и пишем новые стандарты 😉 .

  • Вообще, правило составления имен таблиц нужно убрать или изменить. Может оно подходит для разработчиков плагинов для ExpressionEngine, но вряд ли кто-то будет их использовать в собственных разработках.

  • Вообще, правило составления имен таблиц нужно убрать или изменить. Может оно подходит для разработчиков плагинов для ExpressionEngine, но вряд ли кто-то будет их использовать в собственных разработках.

  • ну радует что дело идет к стандартиризации, это всегда плюс в софт разработках

  • ну радует что дело идет к стандартиризации, это всегда плюс в софт разработках

  • Владимир, придерживаюсь такого же стиля как и вы, судя по вашим замечаниям в статье. Короче, PEAR мне больше по душе.

  • Владимир, придерживаюсь такого же стиля как и вы, судя по вашим замечаниям в статье. Короче, PEAR мне больше по душе.

  • Эти правила кодирования, исходя из вступления, должны быть соблюдены при написании кода для CodeIgniter (имеется ввиду не приложение на его базе, а он сам).
    Кроме того, в тексте то там, то тут встречаются фразы вида «В ExpressionEngine используется», «Контрольная панель должна быть…» и так далее.

    Так что это просто внутренний документ… Который зачем-то решили запихнуть в документацию CodeIgniter .

    PS. Сам я использую немного видоизмененную PEAR-конвенцию. )

    • А если не секрет, что именно не понравилось в PEAR-конвенции? Просто хочется сравнить с собственным мнением.

  • Эти правила кодирования, исходя из вступления, должны быть соблюдены при написании кода для CodeIgniter (имеется ввиду не приложение на его базе, а он сам).
    Кроме того, в тексте то там, то тут встречаются фразы вида «В ExpressionEngine используется», «Контрольная панель должна быть…» и так далее.

    Так что это просто внутренний документ… Который зачем-то решили запихнуть в документацию CodeIgniter .

    PS. Сам я использую немного видоизмененную PEAR-конвенцию. )

    • А если не секрет, что именно не понравилось в PEAR-конвенции? Просто хочется сравнить с собственным мнением.

  • andead

    Всегда используйте одиночные кавычки, если в строке не используется парсинг переменных или другие одиночные кавычки

    сами же предпочитают двойные кавычки) заглянуть хотя бы в config.php

    • Кстати, да. Правда, в версии 1.7 в config.php часть настроек с одиночными кавычками, а часть — с двойными. Может быть к релизу поправят 🙂

  • andead

    Всегда используйте одиночные кавычки, если в строке не используется парсинг переменных или другие одиночные кавычки

    сами же предпочитают двойные кавычки) заглянуть хотя бы в config.php

    • Кстати, да. Правда, в версии 1.7 в config.php часть настроек с одиночными кавычками, а часть — с двойными. Может быть к релизу поправят 🙂

  • Андрей

    хм, а как понять какие переносы строки в редакторе? в FAR под виндами к примеру? и какие редакторы под виндами делают юниксовые переносы?…

    • Можно посмотреть в hex редакторе 🙂
      Но удобнее использовать редактор типа Nodepad++ (меню Вид — Символ конца строки). Из меню Кодировки можно преобразовать в UNIX или MAC форматы.

  • Андрей

    хм, а как понять какие переносы строки в редакторе? в FAR под виндами к примеру? и какие редакторы под виндами делают юниксовые переносы?…

    • Можно посмотреть в hex редакторе 🙂
      Но удобнее использовать редактор типа Nodepad++ (меню Вид — Символ конца строки). Из меню Кодировки можно преобразовать в UNIX или MAC форматы.

  • Pingback: Блог интересующегося » PHP Code Style()

  • мда , можно зделать маленький сборник

  • мда , можно зделать маленький сборник

  • Pingback: Оформление кода()

  • Mail

    «Вместо || нужно использовать OR, но && предпочтительнее AND. Причина – || выглядит похоже на 11.»
    ересь какая-то. никогда не путал вертикальную черту ни с чем другим. вот маленькая L да, похожа, но и только.
    1| l| 1l