Normes de développement des plugins d'application

Exigences des plugins d'application

• Les plugins ne doivent pas contenir de code, d'icônes, d'images, etc. portant atteinte aux droits d'auteur.
• Le code source du plugin doit être complet et ne doit pas être crypté.
• Le plugin doit offrir une fonctionnalité complète et ne peut pas se limiter à des fonctions simples.
• Une présentation complète de la fonctionnalité et de la documentation doivent être fournies.
• L'utilisation de fonctionnalités de coroutines n'est pas recommandée dans les plugins, car les utilisateurs peuvent ne pas avoir activé les coroutines.

Identification des plugins d'application

Chaque plugin d'application a une identification unique, composée de lettres. Cette identification affecte le nom du répertoire source du plugin, le namespace de la classe et le préfixe de la table de base de données du plugin.

Supposons qu'un développeur choisisse foo comme identification du plugin, alors le répertoire source du plugin se trouve à {projet_principal}/plugin/foo, le namespace de la classe correspondante est plugin\foo, et le préfixe de la table est foo_.

Étant donné que l'identification est unique sur l'ensemble du réseau, le développeur doit vérifier la disponibilité de l'identification avant de commencer le développement. L'adresse de vérification est Vérification de l'identification de l'application.

Base de données

• Les noms de table doivent être composés de lettres minuscules a-z et de traits de soulignement _.
• Les tables de données des plugins doivent être préfixées par l'identification du plugin, par exemple, la table article du plugin foo sera foo_article.
• La clé primaire de la table doit être l'id comme index.
• Le moteur de stockage doit utiliser de manière uniforme le moteur innodb.
• L'ensemble de caractères doit utiliser uniformément utf8mb4_general_ci.
• L'ORM de la base de données peut utiliser Laravel ou Think-ORM.
• Les champs temporels doivent idéalement utiliser DateTime.

Normes de code

Normes PSR

Le code doit être conforme aux normes de chargement PSR4.

La nomination des classes doit commencer par une majuscule en style camelCase

<?php

namespace plugin\foo\app\controller;

class ArticleController
{

}

Les attributs et méthodes des classes doivent commencer par une minuscule en style camelCase

<?php

namespace plugin\foo\app\controller;

class ArticleController
{
    /**
     * Méthodes ne nécessitant pas d'authentification
     * @var array
     */
    protected $noNeedAuth = ['getComments'];

    /**
     * Obtenir les commentaires
     * @param Request $request
     * @return Response
     * @throws BusinessException
     */
    public function getComments(Request $request): Response
    {

    }
}

Commentaires

Les attributs et les fonctions des classes doivent inclure des commentaires, comprenant un aperçu, des paramètres et un type de retour.

Indentation

Le code doit être indenté avec 4 espaces au lieu de tabulations.

Contrôle de flux

Les mots-clés de contrôle de flux (if, for, while, foreach, etc.) doivent être suivis d'un espace. La première accolade d'ouverture du code de contrôle de flux doit être sur la même ligne que la parenthèse fermante.

foreach ($users as $uid => $user) {

}

Noms de variables temporaires

Il est conseillé d'utiliser une nomenclature en camelCase commençant par une minuscule (non obligatoire).

$articleCount = 100;