PHP - именование функций / переменных

Question

Я прочитал много популярных руководств по стандартам для проектов PHP с открытым исходным кодом.

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

Должны ли глобальные функции и переменные именоваться иначе, чем методы / свойства класса?

Я знаю, что самая важная вещь - последовательность, но я хотел бы услышать некоторые мысли по этому поводу.

Что бы вы порекомендовали?

Answer 1

Я считаю, что camelCase немного приятнее набирать, потому что подчеркивание немного неудобно печатать.

Не используйте глобальные переменные.

Я избегаю процедурного кодирования в PHP, я считаю, что ООП проще поддерживать порядок. Кроме того, разве у PHP уже недостаточно вещей в своем глобальном пространстве имен?

Обычно я стараюсь придерживаться:

• Классы являются существительными или множественными числами StudlyCaps, в зависимости от ситуации: Item, Row, DB, Items.
• Переменные - это существительные в нижнем регистре, в единственном или множественном числе, в зависимости от того, что они содержат: $column, $name
• Константы являются существительными в верхнем регистре: DEBUG, TYPE_FOO.
• Методы являются camelCase и начинаются с глаголов в единственном числе (get, perform, do), за которыми следует существительное (единственное или множественное число), описывающее, с чем он работает или возвращает (getThing(), getThings()) )

Это определенно зависит от того, для чего вы кодируете. Если я пишу PHP или PEAR, я использую camelCase. Если я делаю Python / Django, я использую under_scores. Если я пишу ELisp, я использую пунктирные разделители.

Answer 2

В самом PHP почти каждая нативная функция разделена подчеркиванием. Большинство примеров кода PHP в документации разделены подчеркиванием.

В большинстве языков я думаю, что Camel или Pascal Casing более уместны, но я думаю, что в PHP есть четкая история использования подчеркивания.

Answer 3

Соглашение об именах Zend Frameworks (основанное на PEAR), вероятно, ближе всего подходит к стандарту в мире PHP. Лично я предпочитаю использовать lowercase_underscore для имен переменных, но в остальном я в основном следую соглашению ZF.

Обновление на 10-летний юбилей:

В наши дни существует стандарт, который в значительной степени принят в сообществе. Вы должны придерживаться этого:

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

Answer 4

Я бы порекомендовал прочитать Стандарты кодирования PEAR . Поскольку PEAR является официальным репозиторием расширений и приложений PHP, его можно считать официальным стандартом кодирования языка.

Answer 5

Моя цель - независимо от конкретного формата имени - добавить больше информации. Улучшает ли имя понимание кода и / или выражает ли что-то важное?

Если это так, отлично, значит, вам это удалось.

Если имя ничего не добавляет, зачем вы его называете?

Я писал об этом ранее на этой неделе:

http://caseysoftware.com/blog/useful-naming-conventions

Answer 6

Раньше я предпочитал использовать camelCase, но для большей согласованности в больших приложениях я принял руководство по стилю CodeIgniter.

Даже если вы не используете их фреймворк, вы можете оценить работу по определению понятных и всеобъемлющих стилей: http://codeigniter.com/user_guide/general/styleguide.html

Answer 7

Примечание: Я использую подчеркивания для своих имен таблиц MySQL, я использую UpperCamelCase для имен полей MySQL:

Обычно я использую $ lowerCamelCase для имен переменных и свойств класса, но если он содержит значение из поля, я использую имя поля $ UpperCamelCase или, если это массив данных из таблицы, я буду использовать $ table_name. Таким образом, я могу легко grep для SomeField или some_table и найти все, что к нему относится.

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

Answer 8

Да, самое важное - это последовательность. Если вы одинокий разработчик, придерживайтесь метода. Если вы работаете с командой, поговорите с другими членами команды. Различение глобальных переменных, функций / методов и классов значительно облегчит чтение кода. Для некоторых людей camelCase проще, чем использование_underlines, поэтому вашей команде необходимо обсудить варианты и выбрать стиль.