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

Как думаете, задумка поможет достичь более понятного и простого взаимодействия между плагинами?

  • Да

    Голосов: 8 100.0%
  • Нет

    Голосов: 0 0.0%

  • Всего проголосовало
    8
Сообщения
198
Реакции
273
Помог
5 раз(а)
Думаю у многих разработчиков возникала проблема: "Бл!*, ну почему этой элементарной вещи здесь нет?" и даже были планы переписать несчастный плагин под свой лад.

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

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

Пользователи, просматривающие эту тему

Сейчас на форуме нет ни одного пользователя.
Сверху Снизу