Спецификация кода и базовых плагинов AMXX.

[BoecSpecOPs]

Думаю у многих разработчиков возникала проблема: "Бл!*, ну почему этой элементарной вещи здесь нет?" и даже были планы переписать несчастный плагин под свой лад.

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

Твоя задача - описать какую элементарную не реализовывал автор стороннего плагина, которая бы сильно упростила тебе жизнь.
Предлагаю примеры тем на выбор:
- Оформление кода/код
- MapManager
- Системы авторизации (идентификация/аутентификация/регистрация)
- Групповые политики (Нужно таки запилить отдельный плагин под группы, а не плодить всякие vip плагины)
- <дополните список отдельным комментарием>

 

[BoecSpecOPs]

DEVCS-2086-30812 (Утверждено 10 Мая 2018)

Начну со спецификации самой спецификации:
Спецификация выполняется в качестве отдельного комментария в посте и описывает необходимые требования к плагину/коду, который будет разработан по этой спецификации.
Идентификацию спецификации проводить следующим образом: DEVCS-<номер_поста-номер_комментария>, для того чтобы можно было ссылаться на спецификацию. (например, данная спецификация имеет номер DEVCS-2086-30812)
Плагин будет называться "поддерживающим спецификацию" DEVCS-<...>, если он выполняет все требования данной спецификации.

Спецификация может быть утверждённой, не утверждённой и устаревшей.
В не утверждённой спецификации допускается применять правки, редактировать и полностью изменять её.
На момент утверждения ставится дата утверждения, после чего дальнейшее редактирование этой спецификации запрещается.
Спецификация считается устаревшей, если есть полностью заменяющая её другая спецификация (в таком случае, должна быть ссылка на новую спецификацию).
Комментировать, предлагать идеи для спецификации разрешается в самой теме. После принятия/отклонения идеи, комментарий будет помечен/удалён.

Спецификация может затрагивать любые аспекты плагина/кода: от требований к API и вплоть до оформления кода и названия объектов (переменных/констант/объявлений и т.д.).

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

-----------------------
Данная тема создана исключительно для спецификации спецификаций (лолшто?).

18 Фев 2018

Пример спецификации по MapManager:

Спойлер: Пример

Должны быть реализованы форварды:
1) mapchooser_onVotePre(bool:is_rtv) - вызывается перед стартом голосования
- Аргументы: является ли голосование досрочным
- По возвращаемому значению - определять запускать ли голосование

2) mapchooser_onVote() - вызывается при штатном голосовании
- Аргументов нет
- Возвращаемое значение игнорируется

3) mapchooser_onVotePost(nextmap[]) - вызывается по окончанию голосования
- Аргументы: название следующей карты (не константа, может быть изменено в другом плагине)
- Возвращаемое значение игнорируется


Должны быть реализованы нативы:
1) mapchooser_isLastRound() -
- Аргументов нет
- Возвращаемое значение: bool - является ли раунд последним?

2) mapchooser_setNextMap(const nextmap[]) - задать следующую карту
- Аргументы: название следующей карты
- Возвращаемое значение: bool - успешность операции

3) <предлагайте идеи>
....