Introduction aux spécifications de développement de codage PHP (avec exemples)

Ce que cet article vous apporte est une introduction aux spécifications de développement de codage PHP (avec des exemples). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Ces derniers jours, j'ai lu un ensemble de spécifications de développement Java "Alibaba Java Development Manual" publié par Alibaba Technology. Il contient les spécifications et les normes de développement Java internes d'Alibaba, et il est très bien écrit. Cet ensemble de spécifications Java unifiées contribuera à améliorer le niveau de normalisation du codage industriel, aidera le personnel de l'industrie à améliorer la qualité et l'efficacité du développement et à réduire considérablement les coûts de maintenance du code.

Après avoir lu ceci, j'ai recherché des spécifications et des normes de développement PHP et j'ai appris que la spécification PSR est un ensemble de normes de développement couramment utilisées dans l'industrie PHP. Je déplore d’avoir si peu appris et d’avoir découvert si tard les normes standards.

En effet, pour les novices ou les développeurs ayant plusieurs années d'expérience, nous devons maîtriser ces spécifications. Dans de nombreux cas, si nous faisons bien ces spécifications, en développement collaboratif, nous pouvons améliorer la qualité et l'efficacité de notre développement. .

Qu'est-ce que le PSR ?

PSR est l'abréviation de PHP Standard Recommendations. La spécification PHP développée par l'organisation PHP FIG est une norme pratique pour le développement PHP.

PHP FIG a actuellement voté pour l'adoption de 6 ensembles de normes et a été pris en charge et reconnu par la plupart des frameworks PHP.

Parmi eux, ceux qui ont réussi sont :

• Spécification de codage de base PSR-1

• Spécification de style de codage PSR-2

• Spécification de l'interface de journal PSR-3

• Spécification de chargement automatique PSR-4

• PSR-6 spécification de l'interface de cache

• Spécification de l'interface de message HTTP PSR-7

*Remarque : PSR-0 est obsolète et PSR-5 est toujours en cours de rédaction et le sera être ajouté plus tard

Ici, nous introduisons d'abord les normes de codage de base PSR-1

1 Présentation

Les fichiers de code PHP doivent se terminer par

Les fichiers de code PHP doivent être codés en UTF-8 sans BOM

Le code PHP ne doit définir que des déclarations telles que des classes, fonctions, constantes, etc., ou pour d'autres opérations qui produiront des effets secondaires (telles que la génération d'une sortie de fichier et la modification des fichiers de configuration .ini, etc.), vous ne pouvez choisir que l'un des deux

<🎜 ; > les espaces de noms et les classes doivent être conformes à la spécification de chargement automatique de PSR : un des [PSR-4](); ; toutes les lettres des constantes de la classe

doivent être suivies. Mettre en majuscule et utiliser des traits de soulignement pour séparer les mots

Les noms de méthodes doivent être conformes à la convention de dénomination camelCase de style camelCase ; en commençant par les minuscules.

2. Fichier

2.1. Balise PHP

Le code PHP doit utiliser la balise longue Ou la balise de sortie courte ne doit pas utiliser d'autres balises personnalisées.

2.2. Encodage des caractères

Le code PHP doit et ne peut utiliser que l'encodage UTF-8 sans BOM. (C'est très important)

2.3. Effets secondaires

Un fichier PHP doit soit définir uniquement de nouvelles déclarations, telles que des classes, des fonctions ou des constantes, etc. produire des effets secondaires, ou simplement écrire des opérations logiques qui produisent des effets secondaires, mais pas les deux en même temps. Le terme « effets secondaires » désigne des opérations logiques effectuées uniquement en incluant des fichiers sans déclarer directement les classes, fonctions, constantes, etc.

Les « effets secondaires » incluent, sans s'y limiter :

Générer une sortie

• Exiger ou inclure directement

• Connecter les services externes

• Modifier la configuration ini

• Lancer une erreur ou une exception

• Modifier des variables globales ou statiques

• Lire ou écrire des fichiers, etc.

Ce qui suit est un contre-exemple, un document contenant une "déclaration de fonction " et "effets secondaires" Code :

Ce qui suit est un exemple, un code qui contient uniquement des déclarations qui ne produisent pas d'"effets secondaires" :

<?php
// 「副作用」：修改 ini 配置
ini_set(&#39;error_reporting&#39;, E_ALL);
// 「副作用」：引入文件
include "file.php";
// 「副作用」：生成输出
echo "<html>\n";
// 声明函数
function foo()
{
   // 函数主体部分
}

3. Espaces de noms et classes

<?php
// 声明函数
function foo()
{
   // 函数主体部分
}
// 条件声明 **不** 属于「副作用」
if (! function_exists(&#39;bar&#39;)) {
   function bar()
   {
       // 函数主体部分
   }
}

La dénomination des espaces de noms et des classes doit suivre [PSR-4](). Selon la spécification, chaque classe est un fichier indépendant et l'espace de noms a au moins un niveau : le nom de l'organisation de niveau supérieur (nom du fournisseur).

La dénomination des classes doit suivre la convention de dénomination des cas de chameau de StudlyCaps en commençant par une majuscule.

Le code pour PHP 5.3 et les versions ultérieures doit utiliser des espaces de noms formels.

Par exemple :

<?php
// PHP 5.3及以后版本的写法
namespace Vendor\Model;
class Foo
{
}

5.2.x 及之前的版本 应该 使用伪命名空间的写法，约定俗成使用顶级的组织名称（vendor name）如 Vendor_ 为类前缀。

<?php
// 5.2.x及之前版本的写法
class Vendor_Model_Foo
{
}

4. 类的常量、属性和方法

此处的「类」指代所有的类、接口以及可复用代码块（traits）。

4.1. 常量

类的常量中所有字母都 必须 大写，词间以下划线分隔。

参照以下代码：

<?php
namespace Vendor\Model;
class Foo
{
   const VERSION = &#39;1.0&#39;;
   const DATE_APPROVED = &#39;2012-06-01&#39;;
}

4.2. 属性

类的属性命名 可以 遵循：

• 大写开头的驼峰式 ($StudlyCaps)

• 小写开头的驼峰式 ($camelCase)

• 下划线分隔式 ($under_score)

本规范不做强制要求，但无论遵循哪种命名方式，都 应该 在一定的范围内保持一致。这个范围可以是整个团队、整个包、整个类或整个方法。

4.3. 方法

方法名称 必须 符合 camelCase() 式的小写开头驼峰命名规范。

【相关推荐：PHP视频教程】

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!