сентября 15 2013
+8

Система именований переменных в Alto CMS

andreyv    15 сентября 2013, 18:58    в избранное в избранном    12 комментариев
Alto CMS inside - как это устроено и работает   
Теги:

Похожие статьи

  • Стиль кодирования
    Общая схема имени переменной выглядит следующим образом: префикс+ДополнительныйПрефикс+ИмяПеременной+Суффикс. Имена переменных содержат латинские буквы верхнего и нижнего регистров и начинаются с префикса, записаного ...

12 комментариев

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

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

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

У нас есть внутреннее соглашение о стиле кодирования, основанном на Zend Style, с некоторыми адаптациями под себя (та же венгерская нотация, например). Но хочется, чтобы это был открытый публичный документ, рекомендованный всем, кто пишет под Альто.
+1
Правда, я не со всем согласен
.
Хотелось бы прийти к общему мнению, поэтому, если возможно, поясните что не нравиться.
0
Ответил чуть выше Вадиму.
+2
Тема отличная. Я считаю, что определенный стиль кодирования — обязательная составляющая «эко-системы», которая выстраивается вокруг движка и уменьшает ее энтропию. А стиль именования переменных — неотъемлемая часть стиля кодирования. Поэтому предлагаю обсудить и выработать, наконец, четко сформулированные правила, которые в дальнейшем будут рекомендованы всем разработчикам на Альто.

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

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

Смешанный тип данных mixed. Та же история, что с «n» — префикс «x» введен с моей подачи. Я его всегда трактовал, как «miXed» :) Мне казалось, что этот префикс как-то более заметен глазом, чем «m», поэтому меньше вероятности ошибки из-за невнимательности.
+2
Я рад, что моя идея стандартизации именований поддерживается, и поддерживается даже на уровне выработки единой концепции, поэтому готов к обсуждению. Ну и по порядку:
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 действительно более заметен, при просмотре кода глаз за него просто цепляется, но нужно-ли это?
0
1 — ок, можно суффиксы и оставить, тем более, что они уже используются (я, правда, не догадывался, что это суффиксы и относился к переменным типа BlogNew так же, как к UserCurrent :)
Но, наверное, стоит тогда более четко их описать, составив примерный перечень.

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

3 — да, аналогия с CMYK очень близкая :), пока не объяснишь — непонятно, но стоит объяснить — как правило, возражений не возникает. Для того и нужны четко прописанные рекомендации с пояснениями, к чему сейчас и идем. И, ИМХО, нужно, чтоб глаз цеплялся. Простой пример (не цитата из кода, но близко):
function GetTopicsByUser($xUser) { /* ... */ }
Тут $xUser может быть как сущностью, так и идентификатором, и очень важно, чтоб разработчик это сразу видел, что нужно обязательно проверить, что передано, прежде чем использовать.
0
По именование массивов (единственное/множественное число) — всегда колебался и не мог определиться, как лучше. Но высказанное предложение готов поддержать.

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

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

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

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