В комментариях к прошлой статье extravert сказал, что для составных префиксов еще не время, и я с ним согласен. Сущности используются очень часто и писать две буквы вместо одной хуже.
По поводу разработчиков — если будет неопытный разработчик — то он, независимо от документа, будет давать имени $s1, $l67 по ему ведомым причинам, опытный разработчик, полюбому, ознакомится с общедоступной документацией.
На счет мапперов (тоже меня опередили) — я пишу статью по стилю кодирования мапперов и вот цитата -«Каждый маппер имеет одну основную таблицу БД с которой он работает». Вторая циатата «Имя маппера состоит из префикса m и имени таблицы БД, представленной в горбатом регистре.»
Исходя из архитектуры LS, модуль может иметь много мапперов — я предлагаю оставить за каждым маппером свою таблицу. (Перекрёстные запросы пока обдумываю)
Геттеры как setter-ы используются только от объекта, то есть
$eUser->getId()
. Через магические вызовы я тоже не хочу использовать, через них только методы модуля, а они, как-раз, с заглавной.
Вы опередили меня в Рекомендациях — GetUsersByFilter() — это, на мой взгляд, не геттер. Геттер получает свойства приватного (защищенного) свойства через обработку его значения, а здесь, в Вашем примере, Get — имя метода, а не префикс геттера. (Подробнее поясню позже, когда допишу статью сущности).
Я использую тот принцип, который описал в статье — префикс обозначает тип, а имя переменной экземпляр типа.
Насчет сущности — это экспромт. Если делать обобщение на всю CMS, то я бы использовал составной тип — «oe» — объекта Entity, «om» — Для маппера, «op» — для плагина, «o» — для неизвестных объектов и т.д., соответсвенно массивы «aoe» — для массива сущностей, «aop» — для массива плагинов, но будет ли это удобно?
Насчет удобства — в API Windows, например тоже есть трех-буквенные префикс, hdc (дескриптор контекста) — так что это тоже вопрос к обсуждению.
Я рад, что моя идея стандартизации именований поддерживается, и поддерживается даже на уровне выработки единой концепции, поэтому готов к обсуждению. Ну и по порядку:
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 действительно более заметен, при просмотре кода глаз за него просто цепляется, но нужно-ли это?
Внесу ноту пессимизма в предложение:
1. Для того, что бы проголосовать за топик(пользователя, блог) посетителю нужно выполнить следующие манипуляции: нажать кнопку голосования, выбрать соцсеть, согласиться с тем, что сайту будет доступна часть информации из этой соцсети — не слишком-ли сложно для простого лайка.
2. В livestreet и соответственно в alto система голосования сложная и предназначается для саморегулирования сообщества (ну как я понял) — вопрос — голоса полуанонимов равносильны голосу зарегистрированного пользователя?
3. Не выродится ли такой плагин в анонимное голосование?
4. Сколько на Вашем сайте человек зарегистрировалось через соцсети? Будет ли количество голосов от этого плагина большим числом?
По поводу разработчиков — если будет неопытный разработчик — то он, независимо от документа, будет давать имени $s1, $l67 по ему ведомым причинам, опытный разработчик, полюбому, ознакомится с общедоступной документацией.
На счет мапперов (тоже меня опередили) — я пишу статью по стилю кодирования мапперов и вот цитата -«Каждый маппер имеет одну основную таблицу БД с которой он работает». Вторая циатата «Имя маппера состоит из префикса m и имени таблицы БД, представленной в горбатом регистре.»
Исходя из архитектуры LS, модуль может иметь много мапперов — я предлагаю оставить за каждым маппером свою таблицу. (Перекрёстные запросы пока обдумываю)
Вы опередили меня в Рекомендациях — GetUsersByFilter() — это, на мой взгляд, не геттер. Геттер получает свойства приватного (защищенного) свойства через обработку его значения, а здесь, в Вашем примере, Get — имя метода, а не префикс геттера. (Подробнее поясню позже, когда допишу статью сущности).
Насчет сущности — это экспромт. Если делать обобщение на всю CMS, то я бы использовал составной тип — «oe» — объекта Entity, «om» — Для маппера, «op» — для плагина, «o» — для неизвестных объектов и т.д., соответсвенно массивы «aoe» — для массива сущностей, «aop» — для массива плагинов, но будет ли это удобно?
Насчет удобства — в API Windows, например тоже есть трех-буквенные префикс, hdc (дескриптор контекста) — так что это тоже вопрос к обсуждению.
Хотелось бы прийти к общему мнению, поэтому, если возможно, поясните что не нравиться.
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 действительно более заметен, при просмотре кода глаз за него просто цепляется, но нужно-ли это?
1. Для того, что бы проголосовать за топик(пользователя, блог) посетителю нужно выполнить следующие манипуляции: нажать кнопку голосования, выбрать соцсеть, согласиться с тем, что сайту будет доступна часть информации из этой соцсети — не слишком-ли сложно для простого лайка.
2. В livestreet и соответственно в alto система голосования сложная и предназначается для саморегулирования сообщества (ну как я понял) — вопрос — голоса полуанонимов равносильны голосу зарегистрированного пользователя?
3. Не выродится ли такой плагин в анонимное голосование?
4. Сколько на Вашем сайте человек зарегистрировалось через соцсети? Будет ли количество голосов от этого плагина большим числом?