PQRS (Plugin Quality Requirement Standards)

Discussion in 'Resources' started by SOFe, Feb 4, 2017.

  1. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin Noobiest member in the PMMP Team

    Messages:
    1,702
    GitHub:
    sof3
    In sight of the recent increase long-lasting tend in low quality plugins that would provide unfavourable plugin intercompatibility, the following guidelines (Plugin Quality Requirement Standards, PQRS) are provided to developers as standards when developing plugins. This post uses key words in RFC 2119 and RFC 6919 to indicate requirement levels.

    ===

    MIGRATED: See the file at https://github.com/poggit/support/blob/master/pqrs.md instead.

    ===

    Should anything be added, removed or amended, feel free to reply below.

    The above standards will be brought into consideration in Poggit plugin reviewing.
     
    Last edited: Feb 22, 2017
  2. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer Verified

    Messages:
    1,374
    GitHub:
    robske110
    I just realized that I never thought about checking if my plugin still exists onCompletion in AsyncTasks.
     
  3. Thunder33345

    Thunder33345 Moderator Staff Member Verified

    Messages:
    2,113
    GitHub:
    Thunder33345
    Developer shouldnt create multiple commands if it is not something very useful, this is subjective but: you shouldnt name something like /credits for your plugin credits as an obvious examples it should be stacked on top of subcommand like /pluginname credits
    note to self: edit pending to add more points
     
  4. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin Noobiest member in the PMMP Team

    Messages:
    1,702
    GitHub:
    sof3
    PQRS Version 1.1: Renamed to PQRS, Updated content -- made it more precise. Note the changes at the bottom of 1. and 4.
     
  5. Michel5F30

    Michel5F30 Silverfish

    Messages:
    22
    Wow... i really like the PQRS!
    This is what i always missed at bukkit. Glad i've found this thread.

    However, i've got some more software standartisation suggestions:
    • A plugin SHALL use the Logger provided by \pocketmine\plugin\PluginBase#getLogger for any output, not any own / custom / even some system console output.
      • A plugin SHOULD NOT print out sensless or duplicated information in a non-debug state.
        E.g. print "plugin blablabla is enabled" at \pocketmine\plugin\PluginBase#onEnable, PMMP already does this for you, also there often were very detailed outputs needed while the developing process, which were completely unnecessary for the end-user, but never removed.
    • A plugin SHALL use separated \pocketmine\command\CommandExecutor classes if it has more than one command OR more than three subcommands (maybe partly personal preference, but i've seen too many ugly #onCommand methods).
    • A plugin SHALL use at least one separated \pocketmine\event\Listener class, when listened for more than X Events (also maybe personal preference, feel free to define X)
    • A plugin MUST have a properly defined plugin.yml including <...> (not sure if it is identical to the bukkit's plugin.yml? But i've seen too many missing command descriptions / usages / plugin descriptions..., new: permissions?).
    • A plugin MUST protect all its features, which may change any setting by a specific permission
    • A plugin SHALL check and validate all arguments of a command before using it (null-checks, type-checks for non-string values,...).
    • A plugin SHOULD provide configurable messages it prints out to players e.g. by a messages config (to support multiple languages or make it configurable to the style of a server).
    • Each feature MUST be properly tested before released to public (maybe some more details, what is "properly").
    • A plugin SHALL store player relevant data by the players UUID, not its name.
    • A plugin MUST provide a complete documentation including all commands (and subcommands), permissions and features before releasing it to publicity.
    These are mostly general programming guides, nevertheless the most-seen annoying things i was faced with at my bukkit times.
     
    Thunder33345 likes this.
  6. Thunder33345

    Thunder33345 Moderator Staff Member Verified

    Messages:
    2,113
    GitHub:
    Thunder33345
    good suggestions in my opinion
    some feedbacks:
    while the first one is logical, i believe unless there's good reasoning it should always use PluginBase#getLogger, like you made your custom system which is for whatever reason better than the normal one since the capability to create custom one is there for a reason
    i agree plugin should never use echo() for end user unless plugin's "debug mode" is enabled

    the idea of needing a new class for each command or for X amount of event may be too restricting but i agree on too many ugly #onCommand and crammed event listeners we all had seen

    and normally developers dont expect people to read the "description" inside of the plugin.yml so normally it's blank/untouch/unhelpful description

    i guess i mildly agree on the checks and enforced to have setting/perm node

    regarding configurable message, yes this should ALREADY be done, its kinda an overdue thing with lack of good custom lang support

    and i agree we should stop using names as it's now changeable

    dont really have comments on the check and descriptions but i think these should be put somewhere else as this should be a codestyle/quality guide
     
  7. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin Noobiest member in the PMMP Team

    Messages:
    1,702
    GitHub:
    sof3
    Feel free to create a pull request on the poggit/support repo if you have motions of amendment.
     
  8. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin Noobiest member in the PMMP Team

    Messages:
    1,702
    GitHub:
    sof3
    This is personal reference. PQRS is intended to maintain intern-plugin compatibility and improve user experience with many plugins, not to regulate code style.
    Also personal preference. This doesn't really affect other plugins or the user by any means.
    I would rather go for "config" instead of "permissions", because it's much more likely that people want to totally disable it.
    Valid, but not within the scope of PQRS. Maybe in another document, or in PQRS v2 to include things not related to compatibility.
    A plugin should support internationalization anyway, and PocketMine's translations system sucks. Not the fault of plugins. I'm working on libglocal for a plugin translation system.
    Pretty much common sense, yet people won't do it :( and we don't know if people do it or just missed something.
    Interesting. But I guess you should first ask for PocketMine to change the way it's saving player data :/ (Correct me if I am outdated)
    Mostly the responsibility of other utilities, e.g. /help and permission managers, to display them properly.
     
    SalmonDE likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.