En raison de la flexibilité de PHP, de nombreuses personnes ne font pas attention à une bonne spécification de code lors de l'écriture du code, ce qui rend le code PHP déjà flexible confus. En fait, la spécification PSR PSR. -1 et PSR-2 ont défini certaines spécifications dans le codage PHP Tant que nous suivons bien ces spécifications, nous pouvons écrire un code très beau et soigné même en utilisant un langage de script flexible. Tout d’abord, examinons les spécifications PSR adoptées, puis expliquons brièvement certaines des exigences spécifiques des spécifications PSR-1 et PSR-2.
PSR réussi
PSR编号 | 名称 | 说明 |
---|---|---|
1 | 基础编码规范 | 关于PHP标签和基本命名约定等基础的规范 |
2 | 编码风格规范 | 关于大括号的位置和参数列表等编码格式的规定 |
3 | 日志接口规范 | 关于日志级别以及记录日志的行为的规定 |
4 | 自动加载规范 | 关于类和命名空间的命名约定,以及它们与文件系统间映射的规定 |
6 | 缓存接口规范 | 关于缓存管理的规定,其中包括数据类型、缓存项的生存周期、错误处理等 |
7 | HTTP消息接口规范 | 关于HTTP请求和响应的约定 |
Spécifications de codage de base PSR-1
1. Balises d'ouverture et de fermeture
Tout d'abord, le code PHP. doit être Commence par une balise
2. Effets secondaires
Les fichiers PHP déclarent des classes, des interfaces, des fonctions, etc., ou effectuent des opérations logiques (telles que lire et écrire des fichiers ou envoyer une sortie à le navigateur), mais cela ne devrait pas être les deux.
3. Dénomination
La dénomination des classes doit respecter la convention de dénomination des cas de chameau qui commence par une lettre majuscule. En d’autres termes, les noms de classes doivent commencer par une lettre majuscule. Il n'est pas obligatoire de nommer les propriétés, mais elles doivent être cohérentes. Les noms de méthodes doivent être conformes à la convention de dénomination camelCase commençant par des minuscules. Toutes les lettres des constantes de classe doivent être en majuscules et les mots séparés par des traits de soulignement.
Spécification du style de codage PSR-2
1. PSR-1 nécessite que le code PHP commence par
PSR-2 stipule que les fichiers PHP purs ne doivent pas se terminer par une balise ?>, mais doivent se terminer par une ligne vide.
2. Une ligne vide doit être insérée après la déclaration de l'espace de noms, et il doit également y avoir une ligne vide après le bloc d'instruction use.
Ne faites pas de déclarations d'utilisation multiples dans la même ligne de code.
3. Le début et la fin de la classe
Le mot-clé class, le nom de la classe et les mots-clés extends et Implements doivent être sur la même ligne. Si une classe implémente plusieurs interfaces, les noms d'interface peuvent figurer sur la même ligne de la déclaration de classe ou occuper des lignes distinctes. Si vous choisissez de placer ces noms d'interface sur plusieurs lignes, le premier nom d'interface doit être sur sa propre ligne et ne pas suivre le mot-clé Implements. L'accolade ouvrante ({) d'une classe doit être écrite sur sa propre ligne après la déclaration de la fonction, et l'accolade fermante (}) doit également être écrite sur sa propre ligne après le corps de la classe. Autrement dit, la déclaration de classe ressemble à ceci
class EarthGame extends Game implements Playable, Savable { //类体 }
Il est également possible de mettre le nom de la classe sur la même ligne que la déclaration de classe.
class EarthGame extends Game implements Playble, Savable { //类体 }
4. Déclaration d'attribut
Chaque attribut doit avoir un modificateur d'accès (public, privé ou protégé). Les attributs ne peuvent pas être déclarés à l'aide du mot-clé var. La spécification des noms d'attributs est déjà couverte dans PSR-1 : vous pouvez utiliser des traits de soulignement, des noms camelCase minuscules ou des noms camelCase majuscules, mais doivent rester cohérents. (Personnellement, je recommande d'utiliser la casse camel minuscule pour les attributs)
5. Le début et la fin de la méthode
Toutes les méthodes doivent avoir des modificateurs d'accès (publics, privés ou protégés) . Le modificateur d'accès doit être après abstract ou final et avant static. Les paramètres de méthode avec des valeurs par défaut doivent être placés à la fin de la liste des paramètres.
QuantityDéclaration sur une seule ligne
L'accolade ouvrante ({) de la méthode doit être écrite sur sa propre ligne après le nom de la méthode, et l'accolade fermante (}) doit également être écrite sur sa propre ligne après le corps de la méthode (suivant directement le code de la méthode). Les listes de paramètres de méthode ne doivent pas commencer ni se terminer par un espace (c'est-à-dire qu'elles doivent suivre les parenthèses qui les entourent). Pour chaque paramètre, il doit y avoir une virgule après le nom du paramètre (ou la valeur par défaut) et un espace après la virgule. Cela peut sembler compliqué, comme indiqué ci-dessous :
final public static function generateTile(int $diamondCount, bool $polluted = false) { //方法体 }
Déclaration sur plusieurs lignes
Si la méthode a de nombreux paramètres, alors une déclaration de méthode sur une seule ligne n'est pas pratique. À ce stade, nous pouvons diviser la liste des paramètres afin que chaque paramètre (y compris le type, la variable de paramètre, la valeur par défaut et la virgule) se trouve sur une ligne en retrait distincte. Dans ce cas, la parenthèse fermante doit être placée sur la ligne après la liste des paramètres, alignée avec le début de la déclaration de la méthode. L'accolade ouvrante ({) doit suivre la parenthèse fermante sur la même ligne, séparée par un espace. Le corps de la méthode doit commencer sur une nouvelle ligne. Encore une fois, cela peut paraître compliqué, mais les exemples suivants devraient vous aider à comprendre cette règle.
public function __construct( int $size, string $name, bool $warparound = false, bool $aliens = false ) { //方法体 }
6. Lignes et indentation
Le code doit être indenté en utilisant 4 espaces au lieu de tabulations. Nous pouvons vérifier les paramètres de l'éditeur et le configurer pour qu'il utilise 4 espaces au lieu de tabulations lorsque la touche de tabulation est enfoncée. Chaque ligne de code ne doit pas dépasser 120 caractères.
7. Méthodes et appels de fonction
Il ne peut pas y avoir d'espace entre le nom de la méthode et les parenthèses ouvrantes. Les règles relatives aux listes de paramètres dans les appels de méthode sont les mêmes que pour les listes de paramètres dans les déclarations de méthode. En d’autres termes, pour les appels sur une seule ligne, il ne peut y avoir d’espaces après la parenthèse ouvrante ni avant la parenthèse fermante. Chaque paramètre doit être suivi d'une virgule et il doit y avoir un espace avant le paramètre suivant. Si un appel de méthode nécessite plusieurs lignes de code, chaque paramètre doit être sur sa propre ligne et en retrait, et la parenthèse fermante doit être sur sa propre ligne.
$earthGanme = new EarthGame( 5, 'earth', true, true ); $earthGame::generateTile(5, true);
8. Contrôle de processus
Les mots-clés de contrôle de processus (if, pour, pendant, etc.) doivent être suivis d'un espace. Cependant, il ne peut pas y avoir d'espace après la parenthèse ouvrante. De même, il ne peut y avoir d’espace avant la parenthèse fermante. Par conséquent, le contenu doit être parfaitement ajusté entre parenthèses. Contrairement aux déclarations de classe et de fonction (sur une seule ligne), l’accolade ouvrante du code de contrôle de flux doit être sur la même ligne que la parenthèse fermante. L'accolade fermante doit être sur une ligne qui lui est propre. Vous trouverez ci-dessous un exemple simple.
$title = []; for ($x = 0; $x < $diamondCount; $x++) { if ($polluted) { $title[] = new PollutionDecorator(new DiamondDecorator(new Plains())); } else { $title[] = new DiamondDecorator(new Plains()); } }
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!