Как логично и структурно именовать переменные?

Question

[doexec]

Добрый день, коллеги.
Вопрос в целом касается не только PHP, но всё же...
Подскажите, более опытные коллеги, как вы именуете переменные? По какому принципу или алгоритму?
В черновом скрипте в 200й строке я вместо $homepage_product_name пытаюсь обратиться к $product_name_home и т.д.
Чем конкретней я именую переменную, тем больше вариаций в голове по мере роста количества строк в документе...

Может кто-то поделится своей схемой именования? Желательно с описанием...
Спасибо!

Comments

[Максим Федоров]

homepage_product_name

Главная страница название товара ?
Назввание товара на главной ?

Непонятен смысл этой переменной, а должен быть понятен

[doexec]

Максим Федоров, это название товара на главной.
Смысл имени переменной понятен с того момента, когда придумал, и до тех пор, пока не отвлёкся на более глубокие дебри...
Поэтому и ищу тот самый "стержень", которому стоит придерживаться.

Answer 1

[dollar]

В английском языке существительные в начале превращаются в прилагательные, а в конце - существительное, к которому они относятся.
Сравните: "stone wall" (каменная стена) и "wall stone" (камень из стены).

То есть первым делом нужно определиться с главным существительным, то есть ЧТО имеется в виду. Если это имя, то название переменной должно оканчиваться на _name (или Name в зависимости от стиля).

Далее, если не придираться к правилам, то последовательность прилагательных лучше делать так: чем важнее, тем ближе к существительному.
Шаг первый: product_name
Шаг второй: homepage_product_name (при этом вам должно быть очевидно, что не home_page)

Далее, ничего лишнего быть не должно, и должно максимально точно отражать суть. Например, настройка, говорящая о том, что уведомления можно посылать только если приложение неактивно.
Не правильно: notify_if_inactive (вообще не понятно, не логично)
Правильно: is_notify_if_inactive_only
Приставка is_ в данном случае является соглашением в нашей команде, указывающем, что это булева переменная, можно также юзать b_ например для той же цели. Или, скажем, если это константа или меняется очень редко, можно записать капсом или добавить приставку c_

Вообще дальше уже начинаются тонкости и вкусовщина. Основные принципы изложены выше - это четкий порядок построения и соответствие сути.

Answer 2

[ThunderCat]

Подскажите, более опытные коллеги, как вы именуете переменные?

Максимально близко к естественному языку. А так же желательно с учетом рекомендаций к стандартам именований принятых в конкретном яп, $homepage_product_name == > $nameOfProductOnHomepage, хотя зачем там хоумпэйдж и чем отличается от не на хоумпэйдж - загадка.

Comments

[doexec]

Ну я взял пример из головы прямо сейчас, чтобы было что разобрать в вопросе, поэтому Хоумпейдж здесь абстрактен. Можно прикинуть, что этот продукт просто "featured", рекомендованый и выводится на главной. Пусть будет так.

При такой длине имени переменной ($nameOfProductOnHomepage) я запутаюсь в них гораздо быстрей....

[Максим Федоров]

doexec, если вы в контроллере главной страницы, то в данном контексте есть только название товара, нет других названий у товара, тк нет других страниц

То есть вот тут название товара такое, имя переменной $name
А вот тут друугое, но имя тоже $name

То есть пример -- имя человека:
в институте это имя студента
в общежитите это имя жильца
просто так -- имя гражданина

Как ни крути, в отдельно взятом контексте name и есть name

[ThunderCat]

doexec, вы и в своих будете путаться, просто я слабо представляю реально длинные именования в структурированном проекте с объектами в качестве основы разработки. Как выше написал Максим Федоров - само структурное разложение на объекты уже не даст излишне удлиняться именованиям. В MVC у вас все разобъется на контроллер + экшн + объекты, и внутри код будет вроде:

class IndexController extends Controller {
...
public function indexAction(){
   $product = new Product();
   $product->initById(55);
   echo $product->name; // хотя так конечно же не делают
}
...
}

Answer 3

[Александр]

Я стараюсь делать по такому принципу - $модуль_функция_свойство

Comments

[doexec]

Можешь привести пример с описанием?

[Александр]

doexec, $shop_basket_product или $blog_article_title.
А вообще правильно выше писали, пора переходить на ООП

[Mysterion]

Александр, переход на ООП никак не поможет человеку. Он спрашивает как правильно научиться называть переменные и свойства. ООП за него это делать не будет.
Нормальный код писать и нормально именовать методы/переменные можно и в процедурке.

[ThunderCat]

Mysterion,

переход на ООП никак не поможет человеку.

неверное утверждение, как я уже написал - само разбиение кода на логически вложенные структурные блоки и объекты сильно упрощает именование сущностей, если в процедурном стиле тот же $homepage_product_name хз что это и где, то в ооп будет лежать в IndexController::indexAction() и иметь вид $product->name, что однозначно относит его к главной странице и имени продукта, причем на порядок более коротко и абсолютно логично.

[Mysterion]

ThunderCat, это не от ООП зависит, а от разработчика.
Можно и контроллер создать CategoryController, а в нем будут категории новостей, категории статей и категории товаров в магазине.

[ThunderCat]

Mysterion, Кто же спорит, г**нокодить можно на любой архитектуре, но в ооп структура логичнее изначально, если разработчик не круглый идиот не способный разделять мягкое от теплого, то никакая архитектура не спасет, но я не думаю что категоричность утверждения "переход на ООП никак не поможет человеку" оправдана, во первых вы же не знаете лично человека, чтобы судить о его уровне умственных способностей, верно? А во вторых - не вижу противоречия - даже в приведенном вами примере где все свалено в кучу, структурная организация позволяет сократить именования сущностей и выстроить логику(хотя и извращенную и кривую), суть все же - код более структурно разделен и сущности логически именуются лаконично и без избыточности.

[Mysterion]

ThunderCat, там точно так же нужно придумывать имена свойствам. У автора вопрос "как правильно придумывать". Тот же самый вопрос у него будет с любой архитектурой.
Ни разу не легче в ООП придумывать имена.
Вы когда что-то утверждаете, вспоминайте, что вопрос задает не программист.

[ThunderCat]

Mysterion,

Вы когда что-то утверждаете, вспоминайте, что вопрос задает не программист.

Откуда такой вывод?

Подскажите, более опытные коллеги, как вы именуете переменные?

Человек явно себя позиционирует как программист, то что он неопытен это другое дело, но к вопросу это не относится.

там точно так же нужно придумывать имена свойствам.

Да, но придумывать имена свойствам это совершенно другая задача нежели придумывать имена сотням переменных из спагетти-кода, так как нет структурной вложенности, да и свойства обычно нативнее именуются, name будет и в продукт и в юзер и в других сущностях, при этом это разные "имена".
Сравните: $homepage_product_name и $product->name вызываемый в индексконтроллере::индексэкшене, тут уже не напишешь $name->product, есть четкая последовательность.

[Mysterion]

ThunderCat,
$product_name
$product->name
Не вижу разницы. Почему же Вы сравниваете заведомо ненормальный код с тем кодом, которого у автора нет?
У автора есть код, который не удобно читать. Вы же утверждаете, что переход на ООП решит все его проблемы с этим.
Четкая последовательность не в ООП, она в голове должна быть.
Можно написать и так:
$product->product_name

[ThunderCat]

Mysterion,

$product_name
$product->name
Не вижу разницы.
...
Четкая последовательность не в ООП, она в голове должна быть.

Просто не надо всех считать идиотами, когда человек в лапше пытается вывести какую-то структурность именований, это говорит о нехватке структуры, а не о нехватке мозгов.

[Mysterion]

ThunderCat, как раз таки я и не считаю всех идиотами. Без ООП нет никакой нехватки структуры. Вы сами это придумали. Структурирование кода, его удобство и красота никакого отношения к ООП не имеет.
Вы к нему прицепились так, будто ООП - это панацея от всех "болезней" в программировании.

[ThunderCat]

Mysterion,

Структурирование кода, его удобство и красота никакого отношения к ООП не имеет.

Вообще то основная роль ООП - структурирование кода, изначально даже в ущерб производительности.

Вы к нему прицепились так, будто ООП - это панацея от всех "болезней" в программировании.

Нет конечно, серебряной пули не существует, но знать и уметь в ООП нормальный программист должен.

[klunker]

Mysterion, MVC никто не отменял.

Answer 4

[Stalker_RED]

https://m.habr.com/ru/post/437122/
Статей вроде этой - десятки.

homepage_product_name

Не совсем понятен смысл. на других страницах у этого-же товара другое имя?

Answer 5

[klunker]

Наименования делай какие хочешь, главное чтоб понятно было. А уже как использовать длинные наименования, так используй нормальные IDE с автокомплитом(плюс паттерн MVC). А вообще городить своей огород не нужно в документации почитай про стандарты PSR-0, PSR-1, PSR-4