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.
I just realized that I never thought about checking if my plugin still exists onCompletion in AsyncTasks.
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
PQRS Version 1.1: Renamed to PQRS, Updated content -- made it more precise. Note the changes at the bottom of 1. and 4.
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.
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
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.