Стандарты написания кода экосистемы LiveStreet
Предлагаю вниманию сообщества и, в первую очередь, разработчиков первую версию стандартов по написанию кода для LiveStreet окружения:
Также для тех, кто пишет плагины, будет удобной инструкция по подготовке плагина к выпуску и публикации в каталоге дополнений LiveStreet:
Ваши предложения, рекомендации можно направлять в пулреквесты, создание исюшек на гите или просто комментированием здесь.
Данных документов ранее не существовало, что вводило в некоторое замешательство новых разработчиков, которые не всегда сразу понимали с какой стороны подходить к написанию кода.
кросс пост из гида.
- github.com/psnet/ls-coding-standarts — этот документ регламентирует стандарт написания кода для экосистемы LiveStreet.
Также для тех, кто пишет плагины, будет удобной инструкция по подготовке плагина к выпуску и публикации в каталоге дополнений LiveStreet:
- github.com/psnet/ls-plugins-checking-before-publishing — данный документ содержит рекомендации для проверки плагинов перед тем, как выпустить их в продакшн.
Ваши предложения, рекомендации можно направлять в пулреквесты, создание исюшек на гите или просто комментированием здесь.
Данных документов ранее не существовало, что вводило в некоторое замешательство новых разработчиков, которые не всегда сразу понимали с какой стороны подходить к написанию кода.
кросс пост из гида.
11 комментариев
/application/frontend/skin/developer/forms/form.add.content.tpl
2. В именовании переменных я всегда закладываю движение от сущности. Например, $aFavouriteTopics я напишу наоборот $aTopicsFavourite. Т.е. сначала тип переменной — массив, затем сущность (что содержит переменная) — Topics, а затем все уточнения — Favourite.
3. Рекомендации плагинов я бы дополнил следующим:
— все кириллические слова и словосочетания должны быть вынесены в языковые файлы плагина;
— при совпадении со стандартными сущностями, модулями и мапперами движка, они должны быть унаследованы.
Отображение знаков табуляции (ширина в 2 или 4 символа пробела) у всех настроена по разному и когда код с табами дописывали кодом с пробелами, то такой код обязательно разъездится. Я говорю про случай, когда код начали редактировать с выключенными невидимыми символами и не заметили, что таб вставляет пробелы. Я с таким просто сталкивался. В случае когда используются пробелы разъезжание кода практически невозможно.
Не надоело повторять?
На счет «повторять» — категорически не согласен. Все, что там (altocms.ru/blog/inside/328.html) написано — описание уже существующего кода и, по большей части, кода LS.
Сейчас, авторы плагинов работают по подобию уже написанного, было бы очень замечательно, если бы основные моменты правил кодирования были заранее известны, а не возникали по наитию.
Я бы добавил в стандарт строгое следование PHPDoc. Сейчас заголовочные блоки сделаны не везде, и не всегда по стандарту (например, todo без @).
Это вообще что-то не очень понятное. Комментарий к комментарию с отдельным ключевым словом? KISS