Champ d'application Sauf indication contraire, les exigences des règles suivantes sont entièrement applicables aux projets DoitPHP (Remarque : le fichier de framework PHP de Doitphp, pas les projets PHP développés avec DoitPHP). Si vous aimez les normes de codage suivantes, vous pouvez également les utiliser dans d'autres projets de développement PHP.?

L'importance et les avantages de la normalisation ? Pas de règles, pas de carrés. ? Lorsque le développement d'un projet logiciel adhère à des normes publiques et cohérentes, tous les membres de l'équipe forment et maintiennent un style de codage cohérent, et l'ensemble du document de projet est rédigé par une seule personne. . Le code de chaque programmeur est facile à comprendre pour les autres, améliorant ainsi la maintenabilité du code et réduisant ainsi le co?t de maintenance du logiciel. Dans le même temps, les nouveaux participants peuvent s'adapter rapidement à l'environnement, maximisant ainsi l'efficacité de la coopération au développement des équipes. Un codage standardisé à long terme peut également permettre aux développeurs de développer de bonnes habitudes de codage, de réduire les risques d'erreurs de codage et même de développer une réflexion plus rigoureuse. Le but de ? documenter ? les spécifications est de clarifier nos normes de codage. Nous pensons que les normes ne sont pas la clé du succès d'un projet, mais elles peuvent nous aider à être plus efficaces dans la collaboration en équipe et à accomplir les taches définies plus facilement.

Spécifications et principes d'encodage PHP 1. Format de fichier 1.1 Encodage de fichier : l'encodage de fichier est unifié en UTF-8 (Remarque : pas UTF-8+BOM). 1.2. Balises de code PHP?: utilisez "<?php ?>" à tout moment pour définir votre code PHP. Et "<? ?>" sera interdit. Pour les fichiers de code contenant uniquement du PHP, il est recommandé d'ignorer le "?>" à la fin du fichier pour éviter que des espaces supplémentaires ou d'autres caractères n'affectent le code. 1.3. Règles d'indentation?: utilisez 4 espaces pour l'indentation au lieu de TAB. C'est déjà la norme dans l'industrie PHP, et nous n'allons pas ? aller à contre-courant de la tendance de l'histoire ?. La principale raison d’utiliser des espaces est de donner au code un aspect soigné et ordonné. Parce que dans différents éditeurs, la longueur du caractère de tabulation TAB est différente, mais l'espace est le même. L'utilisation de TAB peut résoudre le problème en appuyant sur la touche TAB, mais l'utilisation d'espaces nécessite d'appuyer quatre fois sur la barre d'espace, ce qui affecte évidemment l'efficacité du développement. à l'heure actuelle, de nombreux éditeurs utilisent par défaut une TAB occupant quatre espaces (le nombre d'espaces qu'il occupe peut être ajusté par l'éditeur, si tel est le cas, afin d'améliorer l'efficacité du développement, vous pouvez utiliser TAB en toute confiance). Cette spécification d'indentation s'applique également aux fonctions, classes, structures logiques, boucles, etc. en JavaScript. 1.4. Contenu du code?: aucun espace supplémentaire ni caractère TAB n'est autorisé à la fin de chaque ligne (assurez-vous que votre éditeur enregistre le fichier au format Unix, ce qui signifie que les lignes se terminent par des nouvelles lignes). à l'exception du fichier de configuration des annotations du module linguistique, il ne peut y avoir de chinois nulle part ailleurs. 1.5 Commentaires de code?: les fichiers doivent avoir des commentaires de code clairs et le style de commentaire adopte la norme phpDocumentor.