Система именований переменных в Alto CMS / Alto CMS inside - как это устроено и работает / Alto CMS

Система именований переменных в Alto CMS (comment #5323)

markus1024@yandex.ru — Mon, 16 Sep 2013 01:44:38 +0400

Жэстачайше плюсую. Почему? Да потому что затронута годная тема, к которой я возвращаюсь каждый раз, открывая свою IDE. Правда, я не со всем согласен, но направление выбрано верное.

Система именований переменных в Alto CMS (comment #5325)

vshemarov@gmail.com — Mon, 16 Sep 2013 12:54:22 +0400

Правда, я не со всем согласен...

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

Система именований переменных в Alto CMS (comment #5355)

markus1024@yandex.ru — Mon, 16 Sep 2013 18:51:35 +0400

А можно попросить в этом месте поподробнее? ...

Я несогласен больше с некоторыми нюансами, но никак точно не со всей затронутой темой. Что именно мне пока кажется лишним:
1) Использование составных префиксов («oe», «op», «oap» и т.д.)
2) Для сущности делать другой префикс (например, как было предложено, у сущности это может быть «e»). Сущности — это наиболее активно использующиеся объекты в коде. Да, есть еще мапперы, но спутать маппер и сущность по своему назначению нереально.

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

Небольшой пример, показывающий важность вопроса. В коде LS/Alto активно используется два префикса: «i» и «n». Тут происходит непонимание (по крайней мере у меня): если в коде идет разделение переменных на целочисленный тип данных и числовой, то где же тогда потерялся Float («f»)?

Система именований переменных в Alto CMS (comment #5363)

vshemarov@gmail.com — Mon, 16 Sep 2013 23:38:55 +0400

… несущая информацию о системе наименований переменных.

Нет, речь не просто о системе именования, а об Alto Coding Style.

У нас есть внутреннее соглашение о стиле кодирования, основанном на Zend Style, с некоторыми адаптациями под себя (та же венгерская нотация, например). Но хочется, чтобы это был открытый публичный документ, рекомендованный всем, кто пишет под Альто.

Система именований переменных в Alto CMS (comment #5330)

andreyv@gladcode.ru — Mon, 16 Sep 2013 14:09:59 +0400

Правда, я не со всем согласен

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

Система именований переменных в Alto CMS (comment #5359)

markus1024@yandex.ru — Mon, 16 Sep 2013 20:03:47 +0400

Ответил чуть выше Вадиму.

Система именований переменных в Alto CMS (comment #5324)

vshemarov@gmail.com — Mon, 16 Sep 2013 12:52:42 +0400

Тема отличная. Я считаю, что определенный стиль кодирования — обязательная составляющая «эко-системы», которая выстраивается вокруг движка и уменьшает ее энтропию. А стиль именования переменных — неотъемлемая часть стиля кодирования. Поэтому предлагаю обсудить и выработать, наконец, четко сформулированные правила, которые в дальнейшем будут рекомендованы всем разработчикам на Альто.

Теперь по существу.

Suffix – семантический суффикс. Я бы предложил отказаться от семантического суффикса в именах переменных. Ну, или назвал бы его использование нежелательным. Например:

$oCurrentUser; // Это нормальное именование переменной без суффикса
$oUserCurrent; // А здесь то ли суффикс Current используется, то ли это плохое знание англ. языка

Префиксы числовых типов. Тотальное использование префикса «n» в числовых переменных, наверное, моя заслуга. Мне всегда казалось более разумным в языке без строгой типизации не разделять целочисленные и вещественные типы данных. В подавляющем числе случаев нам важно знать тип переменной, чтобы понимать, какие операции с ней возможно. И с этой точки зрения int и float идентичны. Но если это вызывает какие-то проблемы у разработчиков и они выскажутся за разделение на i/f — я возражать не буду.

Смешанный тип данных mixed. Та же история, что с «n» — префикс «x» введен с моей подачи. Я его всегда трактовал, как «miXed» :) Мне казалось, что этот префикс как-то более заметен глазом, чем «m», поэтому меньше вероятности ошибки из-за невнимательности.

Система именований переменных в Alto CMS (comment #5329)

andreyv@gladcode.ru — Mon, 16 Sep 2013 14:08:17 +0400

Я рад, что моя идея стандартизации именований поддерживается, и поддерживается даже на уровне выработки единой концепции, поэтому готов к обсуждению. Ну и по порядку:
1. Без суффиксов обойтись нельзя. Стандартные суффиксы, которые присутствуют в большинстве языков должны быть, иначе, если их включать в часть имени, будет больше непоняток. Суффиксы, которые бы я оставил – Last, First (хотя его и нет в CMS), Limit, New, Old. Могу сказать из личного опыта – я использую суффиксы, в большинстве php-кода, который я видел используются суффиксы, и жестко отменять их для конкретной CMS не вижу смысла, лучше определить их набор исходя из архитектуры CMS. Да, отношение к $oUserCurrent у меня такое же как и у Вас ).
2. По поводу префикса «n». Да PHP, без строгой типизации, однако целые и вещественные типы там различаются. Псевдотип number определен как обобщенный и, мое мнение, так и должен использоваться, то есть с последующей проверкой типа – аналогично mixed. Я не отрицаю возможность его использования, просто конкретизирую.
3. Mixed. Знаете, есть такая цветовая модель CMYK, где первые буквы модели обозначают цвета (CMYK: Cyan, Magenta, Yellow), а последняя буква К – blacK. Я ни разу не подумал о том, что x – это miXed. Это, наверное еще раз говорит в пользу необходимости общей концепции именования. В дополнение – да X действительно более заметен, при просмотре кода глаз за него просто цепляется, но нужно-ли это?

Система именований переменных в Alto CMS (comment #5362)

vshemarov@gmail.com — Mon, 16 Sep 2013 23:27:04 +0400

1 — ок, можно суффиксы и оставить, тем более, что они уже используются (я, правда, не догадывался, что это суффиксы и относился к переменным типа BlogNew так же, как к UserCurrent :)
Но, наверное, стоит тогда более четко их описать, составив примерный перечень.

2 — уже двое высказалось за разделение «n» на «i» и «f». Возможно, что стоит это сделать.

3 — да, аналогия с CMYK очень близкая :), пока не объяснишь — непонятно, но стоит объяснить — как правило, возражений не возникает. Для того и нужны четко прописанные рекомендации с пояснениями, к чему сейчас и идем. И, ИМХО, нужно, чтоб глаз цеплялся. Простой пример (не цитата из кода, но близко):

function GetTopicsByUser($xUser) { /* ... */ }

Тут $xUser может быть как сущностью, так и идентификатором, и очень важно, чтоб разработчик это сразу видел, что нужно обязательно проверить, что передано, прежде чем использовать.

Система именований переменных в Alto CMS (comment #5326)

vshemarov@gmail.com — Mon, 16 Sep 2013 13:03:49 +0400

По именование массивов (единственное/множественное число) — всегда колебался и не мог определиться, как лучше. Но высказанное предложение готов поддержать.

Насчет того, чтоб сущности обозначать префиксом «e», а все остальные объекты «o» — как-то даже и не знаю. Здравое зерно в этом есть. Но в то же время получается, что, хоть по сути своей entity — это object, но у нас o(bject) — это любой объект, кроме e(ntity). Поэтому хотелось бы выслушать мнения других разработчиков

Система именований переменных в Alto CMS (comment #5331)

andreyv@gladcode.ru — Mon, 16 Sep 2013 14:21:12 +0400

Я использую тот принцип, который описал в статье — префикс обозначает тип, а имя переменной экземпляр типа.

Насчет сущности — это экспромт. Если делать обобщение на всю CMS, то я бы использовал составной тип — «oe» — объекта Entity, «om» — Для маппера, «op» — для плагина, «o» — для неизвестных объектов и т.д., соответсвенно массивы «aoe» — для массива сущностей, «aop» — для массива плагинов, но будет ли это удобно?

Насчет удобства — в API Windows, например тоже есть трех-буквенные префикс, hdc (дескриптор контекста) — так что это тоже вопрос к обсуждению.

Система именований переменных в Alto CMS (comment #5345)

vladimir.o.yuriev@gmail.com — Mon, 16 Sep 2013 16:43:31 +0400

Насчет составных типов, думаю — пока это не нужно.

Спасибо за статью. Перенес в общий блог документации.