Spécification PHP PSR version chinoise_bases de php
Adresse de l'entrepôt du document : https://github.com/hfcorriez/fig-standards
Spécification PSR version chinoise
- Chargement automatique PSR-0
- Spécification du code de base PSR-1
- Style de code PSR-2
- Interface de journal PSR-3
L'extrait traduit une phrase officielle Cette organisation a pour but de discuter de nos projets de code. un terrain d’entente pour trouver une approche de programmation collaborative.
Cela me rappelle ce passage d'un article "Pourquoi Google applique des normes strictes de code" :
Dans Google, je peux afficher n'importe quel code, accéder à toutes les bibliothèques de codes Google et j'ai l'autorisation de les afficher. En fait, très peu de gens ont ce genre d’autorité. Cependant, ce qui m'a surpris, c'est qu'un si grand nombre de normes de codage (indentation, dénomination, structure de fichier, style de commentaire) m'ont toutes permis de lire et de comprendre facilement n'importe quel morceau de code. Cela m’a choqué, parce que je pensais que ces normes étaient insignifiantes. Ils n’auraient pas pu faire autant – et pourtant ils l’ont fait. Lorsque vous constatez que vous pouvez comprendre un morceau de code simplement en regardant la structure syntaxique de base du programme, ce genre de gain de temps ne peut qu'être choquant !
Chers lecteurs, je n'ai pas besoin d'en dire plus sur la réglementation.
Écrivez-le à la fin
Les spécifications ne sont pas obligatoires. Bien sûr, vous pouvez choisir votre propre méthode, mais l'utilisation des spécifications facilitera votre coopération. De nos jours, l'écriture de diverses applications plus modernes n'est plus comme avant. Une application est généralement composée de nombreux modules. Si les spécifications ne sont pas mises en œuvre, cela ne fera que compliquer la compréhension et la communication de l'ensemble du projet.
Si vous utilisez un cahier des charges, les bénéfices pour le projet et pour vous-même vont bien sûr de soi.
Toutes les références de spécifications acceptées : https://github.com/hfcorriez/fig-standards/tree/zh_CN/%E6%8E%A5%E5%8F%97
Spécification du style de code
Le but de ce guide est de réduire les différences cognitives entre les différents développeurs lors de la navigation dans le code. Celui-ci énumère un ensemble de règles communes sur la façon de formater le code PHP.
Les points communs de chaque projet membre forment les règles de style de cet article. Lorsque différents développeurs collaborent sur différents projets, une norme commune sera utilisée dans ces différents projets. L’intérêt de ce guide ne réside donc pas dans les règles elles-mêmes, mais dans leur partage.
Les mots-clés caractéristiques de la RFC 2119 sont « DOIT », « NE DOIT PAS », « REQUIS », « DEVRAIT », « NE DEVRAIT PAS », Les mots « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » seront utilisés dans ce document.
1. Aperçu
Le code doit être conforme au PSR-1.
Le code doit utiliser une indentation de 4 espaces, pas des tabulations.
Il ne devrait y avoir aucune limite stricte sur la longueur d'une ligne de code ; la limite souple doit être de 120 caractères ; elle doit également être de 80 caractères ou moins.
Il doit y avoir une ligne vide sous la déclaration de l'espace de noms, et il doit également y avoir une ligne vide sous le bloc de déclaration use.
L'accolade gauche de la classe doit être placée sur la ligne suivante, et l'accolade droite doit être placée sur la ligne suivante du corps de la classe.
L'accolade gauche d'une méthode doit être placée sur la ligne suivante, et l'accolade droite doit être placée sous le corps de la méthode.
Toutes les propriétés et méthodes doivent avoir des déclarations de visibilité (Note du traducteur : Public, Protect, Private) ; les déclarations abstraites et finales doivent être avant la visibilité ; les déclarations statiques doivent être après la visibilité.
Les mots-clés des structures de contrôle doivent avoir un espace après eux ; les méthodes et les fonctions ne sont pas autorisées.
L'accolade gauche de la structure de contrôle doit être placée sur la même ligne, et l'accolade droite doit être placée sur la ligne suivante du corps de contrôle.
Il ne doit y avoir aucun espace après le support gauche de la structure de contrôle et aucun espace avant le support droit.
1.1. Exemple
Cet exemple contient un affichage simple de certaines des règles ci-dessus :
namespace VendorPackage;
utilisez FooInterface;
utilisez BarClass comme Bar;
utilisez OtherVendorOtherPackageBazClass;
class Foo extends Bar implémente FooInterface
{
public function sampleFunction($a, $b = null)
{
if ($a === $b) {
bar ();
} elseif ($a > $b) {
);
}
}
barre de fonction statique publique finale() {
// corps de la méthode
}
}
Le code doit être conforme à toutes les règles du PSR-1.
2.2 Fichiers
Tous les fichiers PHP doivent se terminer par une ligne vide.
Balise de fermeture de fichier pour du code PHP pur ?>Doit être omis
2.3. Ligne
Il ne peut y avoir de limite stricte sur la longueur de la ligne.
La limite souple de longueur de ligne doit être de 120 caractères ; pour la limite souple, le vérificateur de style automatique doit avertir mais pas d'erreur.
La longueur réelle de la ligne ne doit pas dépasser 80 caractères ; les lignes plus longues doivent être divisées en plusieurs lignes ultérieures de 80 caractères maximum.
Il ne doit y avoir aucun espace après les lignes non vides.
Des lignes vides peuvent être utilisées pour améliorer la lisibilité et distinguer les blocs de code associés.
Il ne doit pas y avoir plus d'une déclaration par ligne.
2.4. Indentation
Le code doit utiliser 4 espaces pour l'indentation, et les caractères de tabulation ne peuvent pas être utilisés comme indentation.
Remarque : l'utilisation uniquement d'espaces, non mélangés à des tabulations, permettra d'éviter certains problèmes de différences de code, de correctifs, d'historique et de commentaires. L'utilisation d'espaces permet également d'ajuster très facilement des indentations subtiles pour améliorer l'alignement entre les lignes.
2.5. Les mots-clés et les mots-clés True/False/Null
PHP doivent être en minuscules.
Les constantes PHP true, false et null doivent être en minuscules.
3. Déclarations d'espace de noms et d'utilisation
Si elle est présente, il doit y avoir une ligne vide après la déclaration d'espace de noms.
Si elles sont présentes, toutes les instructions d'utilisation doivent être placées sous l'instruction d'espace de noms.
Un mot-clé use doit être utilisé dans une seule déclaration.
Il doit y avoir une ligne vide après le bloc de déclaration d'utilisation.
Exemple :
utilisez FooClass;utilisez BarClass comme Bar;
utilisez OtherVendorOtherPackageBazClass;
// ... code PHP supplémentaire ...
4.1. Extension et héritage
L'accolade gauche de la classe doit être placée sur sa propre ligne en dessous ; l'accolade droite doit être placée sur sa propre ligne après le corps de la classe.
utilisez FooClass;
utilisez BarClass comme Bar;
utilisez OtherVendorOtherPackageBazClass;
class ClassName extends ParentClass implémente ArrayAccess, Countable{
// constantes, propriétés, méthodes
}
utilisez FooClass;utilisez BarClass comme Bar;
utilisez OtherVendorOtherPackageBazClass;
class ClassName étend les implémentations ParentClass
Countable,
Serialisable
{
// constantes, propriétés, méthodes
}
4.2. Attributs
Tous les attributs doivent déclarer la visibilité.
Le mot-clé var ne peut pas être utilisé pour déclarer des attributs.
Une seule instruction ne peut pas déclarer plusieurs attributs.
Les noms de propriétés ne doivent pas être préfixés par un seul trait de soulignement pour indiquer une visibilité protégée ou privée.
Une déclaration de propriété devrait ressembler à ceci.
espace de noms VendorPackage ;
class ClassName
{
public $foo = null;
}
4.3. Méthodes
Toutes les méthodes doivent déclarer la visibilité.
Les noms de méthodes ne doivent pas utiliser un seul trait de soulignement pour indiquer une visibilité protégée ou privée.
Le nom de la méthode ne peut pas être suivi d'un espace après la déclaration. L'accolade ouvrante doit être placée sur sa propre ligne en dessous, et l'accolade fermante doit être placée sur sa propre ligne en dessous du corps de la méthode. Il ne doit y avoir aucun espace après le crochet de gauche ni aucun espace avant le crochet de droite.
Une définition de méthode devrait ressembler à ce qui suit. Notez les crochets, les virgules, les espaces et les accolades :
espace de noms VendorPackage ;
class ClassName
{
public function fooBarBaz($arg1, &$arg2, $arg3 = [])
{
// corps de la méthode
}
}
4.4.Paramètres de la méthode
Dans la liste des paramètres, il ne doit y avoir aucun espace avant la virgule, et il doit y avoir un espace après la virgule.
Les paramètres avec des valeurs par défaut dans les méthodes doivent être placés à la fin de la liste des paramètres.
espace de noms VendorPackage ;
class ClassName
{
public function foo($arg1, &$arg2, $arg3 = [])
{
// corps de la méthode
}
}
La liste des paramètres peut être divisée en plusieurs lignes suivantes avec une seule indentation. Si vous faites cela, le premier élément de la liste doit être placé sur la ligne suivante et un seul paramètre doit être placé sur chaque ligne.
Lorsque la liste des paramètres est divisée en plusieurs lignes, l'accolade droite et l'accolade gauche doivent être placées ensemble avec un espace pour former leur propre ligne.
espace de noms VendorPackage ;
class ClassName
{
public function aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
) array $arg3 = []
) {
// corps de la méthode
}
}
4.5. abstraite, finale et statique
Si présentes, les déclarations abstraites et finales doivent être placées avant la déclaration de visibilité.
Si présente, une déclaration statique doit être suivie d'une déclaration de visibilité.
espace de noms VendorPackage ;
classe abstraite ClassName
{
protected static $foo;
fonction protégée abstraite zim();
barre de fonction statique publique finale()
{
// corps de la méthode
}
}
4.6. Appel de méthodes et de fonctions
Pour appeler une méthode ou une fonction, il ne doit y avoir aucun espace entre le nom de la méthode ou de la fonction et le crochet gauche, aucun espace après le crochet gauche et aucun espace avant le crochet droit. Dans la liste des fonctions, il ne doit y avoir aucun espace avant la virgule et il doit y avoir un espace après la virgule.
bar();
$foo->bar($arg1);
Foo::bar($arg2, $arg3);
La liste des paramètres peut être Divisé en lignes suivantes avec un retrait. Si vous procédez ainsi, le premier élément de la liste doit être placé sur la ligne suivante et chaque ligne doit avoir exactement un argument.
$foo->bar(
$longArgument,
$longerArgument,
$muchLongerArgument
);
5. Kontrollstruktur
Die Stilregeln für Kontrollstrukturen sind wie folgt zusammengefasst:
Nach dem Schlüsselwort der Kontrollstruktur muss ein Leerzeichen stehen.
Nach der linken Klammer darf kein Leerzeichen stehen.
Vor der rechten Klammer darf kein Leerzeichen stehen.
Zwischen der rechten Klammer und muss ein Leerzeichen stehen die linke geschweifte Klammer
Code Der Körper muss einmal eingerückt werden
Die schließende geschweifte Klammer muss eine Zeile unter dem Körper stehen
Der Körper jeder Struktur muss in geschweifte Klammern eingeschlossen sein. Diese Struktur sieht standardisierter aus und verringert die Möglichkeit von Fehlern beim Hinzufügen neuer Zeilen.
5.1. if, elseif, else
Eine if-Struktur sollte wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern; sonst und elseif stehen auf derselben Zeile wie die schließende geschweifte Klammer des vorherigen Textkörpers.
if ( $expr1) {
// if body
} elseif ($expr2) {
// elseif body
} else {
// else body;
}
Das Schlüsselwort elseif sollte anstelle von else if verwendet werden, um alle Kontrollschlüsselwörter als ein Wort beizubehalten.
5.2. Schalter, Gehäuse
Eine Schalterstruktur sollte wie folgt aussehen. Achten Sie auf Klammern, Leerzeichen und geschweifte Klammern. Die Case-Anweisung muss vom Schalter aus eingerückt sein, und das Schlüsselwort break (oder ein anderes Schlüsselwort break) muss auf derselben Ebene wie der Case-Körper eingerückt sein. Wenn ein nicht leerer Fallkörper herunterfällt, muss ein Kommentar wie // no break vorhanden sein.
Schalter ( $expr) {
case 0:
echo 'Erster Fall, mit Pause';
break;
case 1:
echo 'Zweiter Fall, der durchfällt';
// keine Pause
case 2:
case 3:
case 4:
echo 'Dritter Fall, Rückkehr statt Pause';
return;
default:
echo 'Default case ';
break;
}
5.3 while, do while
Eine while-Anweisung sollte wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern.
while ( $expr) {
// Strukturkörper
}
Ähnlich sollte eine do while-Anweisung wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern.
do {
// Strukturkörper;
} while ($expr);
5.4. for
Eine for-Anweisung sollte wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern.
für ( $i = 0; $i < $i++) {
// für Körper
Eine foreach-Anweisung sollte wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern.
// foreach body
}
Eine Try-Catch-Anweisung sollte wie folgt aussehen. Achten Sie auf die Platzierung von Klammern, Leerzeichen und geschweiften Klammern.
cuba {
// cuba badan
} tangkapan (FirstExceptionType $e) {
// tangkap badan
} tangkapan (OtherExceptionType $e) {
// tangkap badan
}
6. Penutupan
Mesti ada ruang selepas kata kunci fungsi apabila penutupan diisytiharkan, dan ruang juga diperlukan sebelum digunakan.
Pendakap kerinting pembukaan mesti berada pada baris yang sama, dan pendakap kerinting penutup mestilah pada barisan badan yang seterusnya.
Mesti tiada ruang selepas kurungan kiri senarai parameter dan senarai pembolehubah, dan mesti tiada ruang sebelum kurungan kanan.
Dalam senarai parameter dan senarai pembolehubah, mesti tiada ruang sebelum koma dan mesti ada ruang selepas koma.
Parameter penutupan dengan nilai lalai mesti diletakkan selepas senarai parameter.
Pengisytiharan penutupan sepatutnya kelihatan seperti berikut. Beri perhatian kepada peletakan kurungan, ruang dan kurungan kerinting.
$closureWithArgs = function ( $arg1, $arg2) {
// body
};
$closureWithArgsAndVars = function ($arg1, $arg2) use ($var1, $var2) {
// body
};
Senarai parameter dan pembolehubah boleh dibahagikan kepada beberapa baris berikutnya dengan satu lekukan. Jika anda melakukan ini, item pertama dalam senarai mesti diletakkan pada baris seterusnya dan hanya satu parameter atau pembolehubah mesti diletakkan pada baris.
Apabila senarai akhir (sama ada parameter atau pembolehubah) dibahagikan kepada berbilang baris, kurungan kanan dan kurungan kerinting kiri mesti diletakkan pada barisnya sendiri dengan ruang.
Di bawah ialah contoh parameter dan senarai pembolehubah yang dipecahkan kepada berbilang baris.
$longArgs_noVars = fungsi (
$longArgument,
$longerArgument,
$muchLongerArgument
) {
// badan
};
$noArgs_longVars = fungsi () gunakan (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// badan
};
$longArgs_longVars = fungsi (
$longArgument,
$longerArgument,
$muchLongerArgument
) gunakan (
$longVar1,
$longerVar2, <3
$mu 🎜 >) {
// badan
};
$longArgument,
$longerArgument,
$muchLongerArgument
) gunakan ($var1) {
// badan
};
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// badan
};
$arg1,
fungsi ($arg2) gunakan ($var1) {
// badan
},
$arg3
);
7. 结论
在该指南中有很多风格的元素和做法有意被忽略掉。这些包括但不局限于：
全局变量和全局常量的声明
方法声明
操作符和赋值
行间对齐
注释和文档块
类名给你前缀和后缀
最佳实践
以后的建议可以修改和扩展该指南以满足这些或其他风格的元素和实践。
附录A 调查
为了写这个风格指南，我们采用了调查个项目以确定共同的做法。这个调查在这里供他人查看。
A.1. 调查数据
url,http://www.horde.org/apps/horde/docs/CODING_STANDARDS,http://pear.php.net/manual/en/standards.php,http://solarphp.com/manual/appendix-standards.style,http://framework.zend.com/manual/en/coding-standard.html,http://symfony.com/doc/2.0/contributing/code/standards.html,http://www.ppi.io/docs/coding-standards.html,https://github.com/ezsystems/ezp-next/wiki/codingstandards,http://book.cakephp.org/2.0/en/contributing/cakephp-coding-conventions.html,https://github.com/UnionOfRAD/lithium/wiki/Spec%3A-Coding,http://drupal.org/coding-standards,http://code.google.com/p/sabredav/,http://area51.phpbb.com/docs/31x/coding-guidelines.html,https://docs.google.com/a/zikula.org/document/edit?authkey=CPCU0Us&hgd=1&id=1fcqb93Sn-hR9c0mkN6m_tyWnmEvoswKBtSc0tKkZmJA,http://www.chisimba.com,n/a,https://github.com/Respect/project-info/blob/master/coding-standards-sample.php,n/a,Object Calisthenics for PHP,http://doc.nette.org/en/coding-standard,http://flow3.typo3.org,https://github.com/propelorm/Propel2/wiki/Coding-Standards,http://developer.joomla.org/coding-standards.html
voting,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,no,no,no,?,yes,no,yes
indent_type,4,4,4,4,4,tab,4,tab,tab,2,4,tab,4,4,4,4,4,4,tab,tab,4,tab
line_length_limit_soft,75,75,75,75,no,85,120,120,80,80,80,no,100,80,80,?,?,120,80,120,no,150
line_length_limit_hard,85,85,85,85,no,no,no,no,100,?,no,no,no,100,100,?,120,120,no,no,no,no
class_names,studly,studly,studly,studly,studly,studly,studly,studly,studly,studly,studly,lower_under,studly,lower,studly,studly,studly,studly,?,studly,studly,studly
class_brace_line,next,next,next,next,next,same,next,same,same,same,same,next,next,next,next,next,next,next,next,same,next,next
constant_names,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper,upper
true_false_null,lower,lower,lower,lower,lower,lower,lower,lower,lower,upper,lower,lower,lower,upper,lower,lower,lower,lower,lower,upper,lower,lower
method_names,camel,camel,camel,camel,camel,camel,camel,camel,camel,camel,camel,lower_under,camel,camel,camel,camel,camel,camel,camel,camel,camel,camel
method_brace_line,next,next,next,next,next,same,next,same,same,same,same,next,next,same,next,next,next,next,next,same,next,next
control_brace_line,same,same,same,same,same,same,next,same,same,same,same,next,same,same,next,same,same,same,same,same,same,next
control_space_after,yes,yes,yes,yes,yes,no,yes,yes,yes,yes,no,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes,yes
always_use_control_braces,yes,yes,yes,yes,yes,yes,no,yes,yes,yes,no,yes,yes,yes,yes,no,yes,yes,yes,yes,yes,yes
else_elseif_line,same,same,same,same,same,same,next,same,same,next,same,next,same,next,next,same,same,same,same,same,same,next
case_break_indent_from_switch,0/1,0/1,0/1,1/2,1/2,1/2,1/2,1/1,1/1,1/2,1/2,1/1,1/2,1/2,1/2,1/2,1/2,1/2,0/1,1/1,1/2,1/2
function_space_after,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no,no
closing_php_tag_required,no,no,no,no,no,no,no,no,yes,no,no,no,no,yes,no,no,no,no,no,yes,no,no
line_endings,LF,LF,LF,LF,LF,LF,LF,LF,?,LF,?,LF,LF,LF,LF,?,,LF,?,LF,LF,LF
static_or_visibility_first,static,?,static,either,either,either,visibility,visibility,visibility,either,static,either,?,visibility,?,?,either,either,visibility,visibility,static,?
control_space_parens,no,no,no,no,no,no,yes,no,no,no,no,no,no,yes,?,no,no,no,no,no,no,no
blank_line_after_php,no,no,no,no,yes,no,no,no,no,yes,yes,no,no,yes,?,yes,yes,no,yes,no,yes,no
class_method_control_brace,next/next/same,next/next/same,next/next/same,next/next/same,next/next/same,same/same/same,next/next/next,same/same/same,same/same/same,same/same/same,same/same/same,next/next/next,next/next/same,next/same/same,next/next/next,next/next/same,next/next/same,next/next/same,next/next/same,same/same/same,next/next/same,next/next/next
A.2. 调查说明
indent_type: 缩进类型。 tab = "使用制表符"，2 or 4 = "空格数量"
line_length_limit_soft: 行长度的“软”限制，用字符。 ? = 不表示或者数字 no 意为不限制.
line_length_limit_hard: 行长度的"硬"限制，用字符。 ? = 不表示或者数字, no 意为不限制.
class_names: 类名如何命名 lower = 只是小写, lower_under = 小写加下划线, studly = 骆驼型.
class_brace_line : L'accolade gauche d'une classe doit-elle être placée sur la même ligne ou sur la ligne suivante ?
constant_names : Comment nommer les constantes de classe ? upper = majuscule plus délimiteur souligné.
true_false_null : Écrire en toutes lettres ou en majuscules ?
method_names : Comment nommer les méthodes ? camel = chameau, lower_under = minuscule plus délimiteur souligné.
method_brace_line : L'accolade ouvrante de la méthode est-elle sur la même ligne ou sur la ligne suivante ?
control_brace_line : L'accolade gauche de la structure de contrôle est-elle sur la même ligne ou sur la ligne suivante ?
control_space_after : Y a-t-il un espace après le mot-clé de la structure de contrôle ?
always_use_control_braces : toujours utiliser des accolades pour les structures de contrôle ?
else_elseif_line : lors de l'utilisation de else et elseif, doivent-ils être placés sur la même ligne ou sur la ligne suivante ?
case_break_indent_from_switch : combien de fois case et break sont-ils en retrait de l'instruction switch ?
function_space_after : Y a-t-il des espaces dans le nom de la fonction et le crochet gauche de l'appel de fonction ?
closing_php_tag_required : S'il s'agit d'un fichier PHP pur, fermer la balise ?>Est-ce obligatoire ?
line_endings : Quelles fins de ligne utiliser ?
static_or_visibility_first : Lequel vient en premier, statique ou visibilité, lors de la définition d'une méthode ?
control_space_parens : Dans l'expression de la structure de contrôle, y a-t-il un espace après le crochet gauche et avant le crochet droit ? oui = si ( $expr ), non = si ($expr).
blank_line_after_php : Une ligne vide est-elle requise après la balise d'ouverture de PHP ?
class_method_control_brace : La position de l'accolade gauche dans les classes, les méthodes et les structures de contrôle.
A.3. Résultats de l'enquête
indent_type :
onglet : 7
2 : 1
4 : 14
line_length_limit_soft :
?: 2
non : 3
75 : 4
80 : 6
85 : 1
100 : 1
120 : 4
150 : 1
line_length_limit_hard:
?: 2
non : 11
85 : 4
100 : 3
120 : 2
class_names:
?: 1
inférieur : 1
inférieur_under : 1
étudiant : 19
class_brace_line :
suivant : 16
identique : 6
constant_names :
supérieur : 22
true_false_null :
inférieur : 19
supérieur : 3
method_names : Chameau : 21
LOWER_UNDER : 1
Method_brace_line :
Suivant : 15
Idem : 7
Control_line_line :
NEXT : 4
Idem : 18
Control_space _Affter :
non : 2
oui : 20
always_use_control_braces :
non : 3
oui : 19
else_elseif_line :
suivant : 6
pareil : 16
case_break_in dent_from_switch :
0/1 : 4
1/1 : 4
1/2 : 14
function_space_after :
non : 22
closing_php_tag_required :
non : 19
oui : 3
line_endings :
? : 5
LF : 17
static_or_visibility_first :
?: 5
soit : 7
statique : 4
visibilité : 6
control_space_parens:
?: 1
non : 19
oui : 2
blank_line_after_php:
?: 1
non : 13
oui : 8
class_method_control_ brace :
suivant/suivant/suivant : 4
suivant/suivant/identique : 11
suivant/identique/identique : 1
identique/identique/identique : 6
Outils d'IA chauds
Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes
AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.
Undress AI Tool
Images de déshabillage gratuites
Clothoff.io
Dissolvant de vêtements AI
AI Hentai Generator
Générez AI Hentai gratuitement.
Article chaud
Outils chauds
Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit
SublimeText3 version chinoise
Version chinoise, très simple à utiliser
Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP
Dreamweaver CS6
Outils de développement Web visuel
SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)
Comment utiliser la spécification PSR en PHP pour écrire une API
Jun 17, 2023 pm 07:01 PM
Avec le développement rapide d'Internet, de plus en plus d'entreprises et de développeurs commencent à utiliser des API (Application Programming Interfaces) pour créer leurs applications. Les API facilitent l'interaction entre différentes applications et plates-formes. Par conséquent, l’écriture et la conception d’API deviennent de plus en plus importantes. Pour atteindre cet objectif, PHP a implémenté PSR (PHP Standard Recommendation), qui fournit un ensemble de spécifications standard pour aider les programmeurs PHP à écrire des API plus efficaces et plus maintenables. Ci-dessous, nous apprendrons ensemble comment utiliser la spécification PSR pour compiler
Processus de collaboration en équipe PHP et mécanisme de révision du code suivant les spécifications PSR2 et PSR4
Oct 15, 2023 am 10:28 AM
Aperçu du processus de collaboration de l'équipe PHP et du mécanisme de révision du code qui suit les spécifications PSR2 et PSR4 : Dans une équipe PHP, afin d'améliorer la lisibilité, la maintenabilité et l'évolutivité du code, il est très important de suivre les spécifications du code PHP. Cet article expliquera comment suivre les spécifications PSR2 et PSR4 pour établir un processus de collaboration d'équipe PHP efficace et un mécanisme de révision de code, et fournira quelques exemples de code spécifiques. 1. Spécification PSR2 La spécification PSR2 définit le style de codage et les exigences de formatage du code PHP, y compris l'indentation et l'espace entre crochets.
Pratiques de fusion et de refactorisation de code selon les spécifications PSR2 et PSR4
Oct 15, 2023 pm 05:24 PM
Les pratiques de fusion et de refactorisation de code qui suivent les spécifications PSR2 et PSR4 nécessitent des exemples de code spécifiques Introduction : Dans le développement de logiciels, la fusion et la refactorisation de code sont des opérations très courantes. La fusion de code fait référence à la fusion de plusieurs fragments de code dispersés en un seul fichier ou module pour améliorer la lisibilité et la maintenabilité du code. La refactorisation du code fait référence à l'amélioration du code existant pour le rendre plus efficace, évolutif et facile à comprendre. Cet article explique comment suivre les spécifications PSR2 et PSR4 lors de la fusion et de la refactorisation du code, avec des exemples de code spécifiques. 1. Suivez
Partage d'expérience pratique du projet sur les spécifications PSR2 et PSR4
Oct 15, 2023 am 08:49 AM
Partager l'expérience pratique des projets des spécifications PSR2 et PSR4 Préface Dans le développement de logiciels modernes, il est très important de suivre des normes de codage unifiées. Cela peut améliorer la lisibilité et la maintenabilité du code et réduire les frictions dans le travail d'équipe. PHP-FIG (PHPFrameworkInteropGroup) a développé une série de spécifications PSR dont les plus connues sont PSR2 et PSR4. Cet article partagera quelques expériences dans le respect des spécifications PSR2 et PSR4 dans la pratique des projets et fournira quelques
Exemple de démonstration et guide d'utilisation des spécifications PSR2 et PSR4 dans le framework Phalcon
Oct 15, 2023 am 11:33 AM
Exemple de démonstration et guide d'utilisation des spécifications PSR2 et PSR4 dans le framework Phalcon Introduction : Avec la popularité et le développement des logiciels open source, la standardisation du code est devenue un sujet très important. Les spécifications du code peuvent améliorer la lisibilité et la maintenabilité du code, facilitant ainsi la collaboration entre les membres de l'équipe. PHP-FIG a développé une série de spécifications PSR (PHPStandardsRecommendations), dont les plus couramment utilisées sont PSR2 et PSR4. Cet article utilisera le framework Phalcon comme
Processus de développement d'équipe PHP qui adhère aux spécifications PSR2 et PSR4
Oct 15, 2023 am 11:25 AM
Le processus de développement en équipe PHP qui adhère aux spécifications PSR2 et PSR4 nécessite des exemples de code spécifiques. Dans le développement PHP moderne, c'est une bonne pratique de développement de se conformer aux spécifications PSR (PHPStandard Recommendation) formulées par PHPFIG (PHPFrameworkInteropGroup). Parmi eux, PSR2 est une spécification sur le style de codage, tandis que PSR4 est une spécification sur le chargement automatique. Cet article expliquera comment adhérer à ces deux aspects dans le développement d'une équipe
Application et enjeux des spécifications PSR2 et PSR4 en collaboration en équipe
Oct 15, 2023 am 10:07 AM
L'application et les défis des spécifications PSR2 et PSR4 dans la collaboration en équipe nécessitent des exemples de code spécifiques. Dans une équipe de développement logiciel, les spécifications et les conventions sont la clé pour maintenir la cohérence et la maintenabilité du code. Deux spécifications importantes dans le domaine PHP : PSR2 (spécification de style de code PHP) et PSR4 (spécification de chargement automatique) jouent un rôle important dans la collaboration en équipe. Cet article présentera en détail l'application de ces deux spécifications, analysera les défis qui peuvent être rencontrés dans le processus de développement réel et proposera les solutions correspondantes. Tout d’abord, regardons un simple PSR
L'effet des spécifications PSR2 et PSR4 sur l'amélioration de la qualité du code PHP
Oct 15, 2023 am 11:46 AM
L'effet d'amélioration des spécifications PSR2 et PSR4 sur la qualité du code PHP nécessite des exemples de code spécifiques Introduction : Avec le développement de PHP, de plus en plus de développeurs ont rejoint les rangs du développement PHP. Cependant, en raison de diverses habitudes de développement, le code PHP a des styles différents et une mauvaise lisibilité et maintenabilité, ce qui pose des problèmes au développement et à la maintenance du projet. Afin de résoudre ce problème, l'organisation PHPFIG (PHPFrameworkInteropGroup) a proposé le PSR (PHPSta
