Как лучше называть переменные $itemText или $item_text в php?

Question

[Алексей Семёнов]

Собственно вопрос уже к опытным разработчикам)
Просто ситуация такая, что $item_text читать гораздо проще, но как я понимаю это уже устаревшая форма и я даже не знаю как быть.
P.s. я понимаю, что чисто технически нет ни какой разница, но я не хочу из-за такой мелочи превращать свою работу в говнокод :)

Answer 1

[Игорь Воротнёв]

1. Есть всего 2 источника истины - PSR и Coding Standard конкретного проекта или команды.
2. Конкретно PSR-1 говорит следующее:

4.2. Properties

This guide intentionally avoids any recommendation regarding the use of
$StudlyCaps, $camelCase, or $under_score property names.

Whatever naming convention is used SHOULD be applied consistently within a
reasonable scope. That scope may be vendor-level, package-level, class-level,
or method-level.

Кратко: не важно какой стиль вы используете, главное использовать один и тот же. То есть, возвращаемся к второму варианту - стандартны проекта/команды.

3. Что касается "industry standards", то в большинстве современных проектов уже используется camelCase для свойств и методов, PascalCase (StudlyCaps) для файлов, классов и пространств имен.

P.s. я понимаю, что чисто технически нет ни какой разница, но я не хочу из-за такой мелочи превращать свою работу в говнокод :)

Говнокод – это совсем про другое. Если проект использует везде snake_case и вы будете его всегда и везде использовать, на качестве кода это никак не отразится. Consistency matters.

Comments

[DevMan]

Хоть в граните выбивай.

[Александр Афанасьев]

только что столкнулся с проблемой при snake_case. В симфони создал entity, где свойства назвал в таком стиле. Например приватное поле created_at.

Затем попытался вывести это поле в твиге: {{item.created_at}}. Но т к поле приватное, твиг начал искать геттеры:
getCreated_at, isCreated_at created_at().

Но вот проблема - методы то у нас в camelCade, т е getCreatedAt().
Пока вижу 3 варианта:
1) сделать в энтити такие поля публичными
2) серилизовать обьекты перед передачей в твиг
3) называть поля в камел кейс, но тогда в базе эти поля все равно в snake_case создаются. получается что в одном месте кода приходится писать createdAt, в другом created_at(в аннотациях например, когда поле связано один ко многим)

Answer 2

[Anton Mashletov]

Просто всегда делай так:

ClassName / TraitName / InterfaceName
$varibleName
function functionName($paramName)
define('DEFINED_CONSTANT_NAME', 0)

// названия файлов:
ClassName.php — внутри класс (трейт, интерфейс)
init.php / config.php — внутри не класс

Comments

[Кирилл Несмеянов]

А вот на счёт функций я бы поспорил. В пыхе давно уже принято функции объявлять с андерскорами, так что переиначивать на свой лад и вводить другое именование я бы не рекомендовал.

\is_array
\file_get_contens
\function_name
// ...

[Кирилл Несмеянов]

Есть PSR-2, который следует соблюдать.

Который никаким образом не ограничивает именование функций, да ;)

Надо относиться к ним как к нечто обособленному, а не как к примеру для подражания

Напоминаю, что PSR обязывает соблюдать единую стилистику для всей кодовой базы. И хоть stdlib не является частью проекта (т.е. влиять на именование не представляется возможным), но это не отменяет того, что сохранение согласованного именования - предпочтительнее отсебятины.

(к тому же среди них есть и camelCase)

Что-то не припомню таковых. Напомните?

Answer 3

[Orbb]

первый вариант, но я обычно поступаю иначе - просто если начал в проекте писать так или сяк, то так и пиши. Вот если наплодить кашу из разных вариантов уже будет не прикольно)