Selon la situation spécifique, les développeurs moyens sont souvent 10 à 20 % moins efficaces que les excellents développeurs. Les bons développeurs sont plus efficaces car ils possèdent une vaste expérience et de bonnes habitudes de programmation. Les mauvaises habitudes de programmation affecteront l’efficacité. Cet article vous aide à devenir un meilleur programmeur en démontrant quelques bonnes habitudes de programmation.
Ces bonnes habitudes de programmation augmentent non seulement l’efficacité, mais vous permettent également d’écrire du code facile à maintenir tout au long du cycle de vie de votre application. Le code que vous écrivez peut nécessiter beaucoup de maintenance ; la maintenance des applications représente une dépense importante. Développer de bonnes habitudes de programmation peut améliorer la qualité de la conception (comme la modularité), rendant le code plus facile à comprendre et donc plus facile à maintenir, tout en réduisant les coûts de maintenance.
De mauvaises habitudes de programmation entraîneront des défauts de code, le rendant difficile à maintenir et à modifier, et sont susceptibles d'introduire d'autres défauts lors de la modification. Voici cinq bonnes habitudes de programmation qui peuvent aider le code PHP à éviter ces pièges :
◆Utilisez un bon nommage.
◆Divisez en parties plus petites.
◆Ajoutez des commentaires au code.
◆Gérer les conditions d'erreur.
◆N'utilisez pas de copier-coller.
Ces habitudes sont détaillées ci-dessous :
Utiliser un bon nommage
Utiliser un bon nommage est l'habitude de programmation la plus importante car les noms descriptifs rendent le code plus facile à lire et à comprendre. La facilité de compréhension du code dépend de sa capacité à être maintenue à l'avenir. Même si le code n'est pas commenté, il facilitera grandement les modifications futures s'il est facile à comprendre. Le but de cette habitude est de rendre le code que vous écrivez aussi facile à lire et à comprendre qu'un livre.
Mauvaise habitude : noms vagues ou dénués de sens
Le code du listing 1 contient des noms de variables trop courts, des abréviations illisibles et des noms de méthodes qui ne reflètent pas la fonctionnalité de la méthode. Si le nom de la méthode donne l’impression qu’elle est censée faire une chose, alors qu’en réalité elle fait autre chose, cela posera de sérieux problèmes car il sera trompeur.
Listing 1. Mauvaises habitudes : noms vagues ou dénués de sens
<?php
function getNBDay($d){
commutateur($d) {
cas 5 :
cas 6 :
cas 7 :
renvoyer 1 ;
défaut:
retour ($d + 1);
}
}
$day = 5;
$nextDay = getNBDay($day);
echo ("Le jour suivant est : " . $nextDay . "n" )
;
Bonne pratique : noms descriptifs et concis
Le code du listing 2 démontre de bonnes pratiques de programmation. Les nouveaux noms de méthode sont très descriptifs et reflètent l’objectif de la méthode. De même, les noms de variables modifiés sont plus descriptifs. La seule variable qui reste la plus courte est $i, qui dans cette liste est une variable de boucle. Bien que de nombreuses personnes désapprouvent l’utilisation de noms trop courts, il est acceptable (et même bénéfique) de les utiliser dans des variables de boucle car cela indique clairement la fonction du code.
Listing 2. Bonne pratique : noms descriptifs et concis
<?php
définir ('LUNDI', 1);
définir ('MARDI', 2);
définir ('MERCREDI', 3);
définir (« JEUDI », 4) ;
définir ('VENDREDI', 5);
définir ('SAMEDI', 6);
définir ('DIMANCHE', 7);
/*
*
* @param $dayOfWeek
* @return int Jour de la semaine, 1 étant lundi et ainsi de suite.
*/
fonction findNextBusinessDay($dayOfWeek){
$nextBusinessDay = $dayOfWeek ;
commutateur ($ jour de la semaine) {
cas VENDREDI :
cas SAMEDI :
cas DIMANCHE :
$nextBusinessDay = LUNDI ;
casser;
défaut:
$jour ouvrable suivant += 1 ;
casser;
}
retourner $nextBusinessDay ;
}
$jour = VENDREDI ;
$nextBusDay = findNextBusinessDay($jour);
echo ("Le jour suivant est :" . $nextBusDay . "n");
?＞
Nous vous encourageons à diviser les conditions volumineuses en une méthode, puis à nommer la méthode avec un nom qui décrit la condition. Cette technique peut améliorer la lisibilité du code et rendre la condition concrète afin qu’elle puisse être extraite et même réutilisée. Il est également facile de mettre à jour les méthodes si les conditions changent. Étant donné qu’une méthode a un nom significatif, elle reflète l’objectif du code et rend le code plus facile à lire.
en petites parties
avant de poursuivre la programmation. Si vous continuez à programmer tout en résolvant un problème urgent, la fonction deviendra de plus en plus longue. À long terme, ce n'est pas un problème, mais n'oubliez pas de revenir en arrière et de le refactoriser en morceaux plus petits.
La refactorisation est une bonne idée, mais vous devez prendre l'habitude d'écrire du code plus court et plus ciblé. Les méthodes courtes peuvent être lues dans une seule fenêtre et sont faciles à comprendre. Si une méthode est trop longue pour être lue dans une seule fenêtre, elle devient difficile à suivre car vous ne pouvez pas suivre rapidement l'ensemble de l'idée du début à la fin.
Lors de la création de méthodes, vous devez prendre l’habitude que chaque méthode ne fasse qu’une seule chose. C’est une bonne habitude car : premièrement, si une méthode ne fait qu’une seule chose, elle est alors plus susceptible d’être réutilisée ; deuxièmement, une telle méthode est facile à tester ; troisièmement, une telle méthode est facile à comprendre et à modifier.
Mauvaise habitude : méthodes trop longues (faire trop de choses)
Le listing 3 montre une fonction très longue qui pose de nombreux problèmes. Il fait beaucoup de choses, donc ce n'est pas assez compact. Il est également plus facile à lire, à déboguer et à tester. Les choses qu'il fait incluent l'itération sur un fichier, la création d'une liste, l'attribution de valeurs à chaque objet, l'exécution de calculs, etc.
Listing 3. Mauvaise habitude : fonction trop longue
<?php
function writeRssFeed($user)
{
//Obtenir les informations de connexion à la base de données
// recherche les préférences de l'utilisateur...
$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
OU mourir (mysql_error());
// Requête
$perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
mysql_real_escape_string($user));
$result = mysql_query($query, $link);
$max_stories = 25; // par défaut à 25 ;
si ($ligne = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
// je vais récupérer mes données
$perfsQuery = sprintf("SELECT * FROM stories WHERE post_date = '%s'",
mysql_real_escape_string());
$result = mysql_query($query, $link);
$feed = "＜rss version="2.0"＞" .
"<canal>" .
"＜titre＞Mon grand flux＜/titre＞" .
"＜lien＞ http://www.example.com/feed.xml ＜/link＞" .
"＜description＞Le meilleur flux du monde＜/description＞" .
"＜langue＞en-us＜/langue＞" .
"＜pubDate＞Mardi 20 octobre 2008 10:00:00 GMT＜/pubDate＞" .
"＜lastBuildDate＞Mardi 20 octobre 2008 10:00:00 GMT＜/lastBuildDate＞" .
"＜docs＞ http://www.example.com/rss ＜/docs＞" .
"<générateur>Mon générateur de flux</générateur>" .
"＜managingEditor＞ [email protected] ＜/managingEditor＞" .
"＜webMaster＞ [email protected] ＜/webMaster＞" .
"＜ttl＞5＜/ttl＞";
// construit le flux...
while ($row = mysql_fetch_assoc($result)) {
$titre = $ligne['titre'];
$lien = $ligne['lien'];
$description = $ligne['description'];
$date = $ligne['date'];
$guid = $row['guid'];
$feed .= "<élément>";
$feed .= "＜titre＞" . $titre .
$feed .= "＜lien＞" . $lien .
$feed .= "＜description＞ " . $description .= "＜/description＞";
$feed .= "＜pubDate＞" . $date .
$feed .= "＜guid＞" . $guid .
$feed .= "＜/article＞";
}
$feed .= "＜/rss";
// écrit le flux sur le serveur...
echo($feed);
}
?>Si vous écrivez quelques méthodes supplémentaires comme celle-ci, la maintenance deviendra un réel problème.
Bonne habitude : liste de méthodes gérables et spécifiques à une fonction
4 Réécrivez la méthode d'origine en une méthode plus compacte et plus lisible. Dans cet exemple, une méthode longue est décomposée en plusieurs méthodes courtes, et chaque méthode courte est responsable d'une chose. Un tel code est très utile pour une réutilisation et des tests futurs.
Listing 4. Bonne pratique : approche facile à gérer et spécifique à une fonction
<?php
function createRssHeader()
{
renvoie "<rss version="2.0">" .
"<canal>" .
"＜titre＞Mon grand flux＜/titre＞" .
"＜lien＞ http://www.example.com/feed.xml ＜/link＞" .
"＜description＞Le meilleur flux du monde＜/description＞" .
"＜langue＞en-us＜/langue＞" .
"＜pubDate＞Mardi 20 octobre 2008 10:00:00 GMT＜/pubDate＞" .
"＜lastBuildDate＞Mardi 20 octobre 2008 10:00:00 GMT＜/lastBuildDate＞" .
"＜docs＞ http://www.example.com/rss ＜/docs＞" .
"<générateur>Mon générateur de flux</générateur>" .
"＜managingEditor＞ [email protected] ＜/managingEditor＞" .
"＜webMaster＞ [email protected] ＜/webMaster＞" .
"＜ttl＞5＜/ttl＞";
}
fonction createRssFooter()
{
renvoie "＜/canal＞＜/rss＞" ;
}
fonction createRssItem ($title, $link, $desc, $date, $guid)
{
$élément .= "＜élément＞";
$item .= "＜titre＞" . $titre .
$item .= "＜lien＞" . $lien .
$item .= "＜description＞ " . $description .= "＜/description＞";
$item .= "＜pubDate＞" . $date .
$item .= "＜guid＞" . $guid .
$élément .= "＜/élément＞";
retourner $article ;
}
fonction getUserMaxStories($db_link, $default)
{
$perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
mysql_real_escape_string($user));
$result = mysql_query($perfsQuery, $db_link);
$max_stories = $par défaut ;
si ($ligne = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
renvoie $max_stories ;
}
fonction writeRssFeed ($ utilisateur)
{
//Obtenir les informations de connexion à la base de données
$settings = parse_ini_file("rss_server.ini");
// recherche les préférences de l'utilisateur...
$link = mysql_connect($settings['db_host'], $settings['user'],
$settings['password']) OU die(mysql_error());
$max_stories = getUserMaxStories($link, 25);
// je vais récupérer mes données
$newsQuery = sprintf("SELECT * FROM stories WHERE post_date = '%s'",
mysql_real_escape_string(time()));
$result = mysql_query($newsQuery, $link);
$feed = createRssHeader();
$je = 0 ;
// construit le flux...
while ($row = mysql_fetch_assoc($result)) {
si ($i < $max_stories) {
$titre = $ligne['titre'];
$lien = $ligne['lien'];
$description = $ligne['description'];
$date = $ligne['date'];
$guid = $row['guid'];
$feed .= createRssItem($title, $link, $description, $date, $guid);
$i++;
} autre {
casser;
}
}
mysql_close($link);
$feed .= createRssFooter();
// écrit le flux sur le serveur...
echo($feed);
}
?> Il existe également des limites à la division des méthodes longues en méthodes courtes, et une division excessive sera contre-productive. N’abusez donc pas de cette bonne habitude. Diviser le code en gros morceaux peut rendre la lecture aussi difficile que ne pas diviser un code long.
Ajouter des commentaires à votre code
Ajouter de bons commentaires à votre code peut parfois sembler aussi difficile que d'écrire le code. Il n'est pas facile de savoir quoi annoter car on a souvent tendance à annoter ce que fait le code en ce moment. C'est une bonne idée de commenter le but de votre code. Dans le bloc d'en-tête moins évident de la fonction, le lecteur est informé des entrées et des sorties de la méthode, ainsi que de l'objectif initial de la méthode.
Il est courant de commenter ce que fait actuellement le code, mais cela n'est pas nécessaire. Si le code est complexe et que vous devez commenter ce qu'il fait actuellement, cela vous suggérera de réécrire le code pour le rendre plus facile à comprendre. Apprenez à utiliser de bons noms et des méthodes plus courtes pour rendre votre code plus lisible sans fournir de commentaires expliquant leur objectif.
Mauvaise habitude : sur- ou sous-commenter les fonctions
Les commentaires du listing 5 indiquent uniquement au lecteur ce que fait le code : il parcourt une boucle ou ajoute un nombre. Mais il ignore pourquoi il fait son travail actuel. Cela laisse les personnes qui maintiennent le code sans savoir si le code peut être modifié en toute sécurité (sans introduire de nouveaux défauts).
Listing 5. Mauvaise habitude : trop ou pas assez de commentaires sur les fonctions
<?php
classe ResultMessage
{
sévérité $ privée ;
message $privé ;
fonction publique __construct($sev, $msg)
{
$this->gravité = $sev;
$ce->message = $msg;
}
fonction publique getSeverity()
{
return $this->severity ;
}
fonction publique setSeverity($severity)
{
$this->gravité = $gravité ;
}
fonction publique getMessage()
{
renvoie $this->message ;
}
fonction publique setMessage($msg)
{
$ce->message = $msg;
}
}
fonction cntMsgs($messages)
{
$n = 0 ;
/* parcourir les messages... */
foreach($messages en $m) {
if ($m->getSeverity() == 'Erreur') {
$n++; // ajoute un au résultat ;
}
}
retourner $n ;
}
$messages = array(new ResultMessage("Erreur", "Ceci est une erreur !"),
new ResultMessage("Avertissement", "Ceci est un avertissement !"),
new ResultMessage("Erreur", "Ceci est une autre erreur !"));
$errs = cntMsgs($messages);
echo("Il y a des erreurs " . $errs . " dans le résultat.n"
?>
Bonne pratique : fonctions et classes annotées
Les commentaires du listing 6 informent le lecteur sur les classes et les méthodes. but. Ce commentaire explique pourquoi le code fait son travail actuel, ce qui peut être utile lors de la maintenance du code à l'avenir. Le code devra peut-être être modifié à mesure que les conditions changent, mais les modifications sont faciles si l'objectif du code est facilement compris.
Listing 6. Bonne pratique : fonctions et classes annotées
<?php
/**
* La classe ResultMessage contient un message qui peut être renvoyé
* à la suite d'un processus Le message a une gravité et
* message.
*
* @auteur nagood
*
*/
classe ResultMessage
{
sévérité $ privée ;
message $privé ;
/**
* Constructeur pour le ResultMessage qui vous permet d'attribuer
* gravité et message.
* @param $sev Voir {@link getSeverity()}
* @param $msg
* @return type_inconnu
*/
fonction publique __construct($sev, $msg)
{
$this->gravité = $sev;
$ce->message = $msg;
}
/**
* Renvoie la gravité du message.
* "Information", "Avertissement" ou "Erreur".
* @return string Gravité du message
*/
fonction publique getSeverity()
{
return $this->severity ;
}
/**
* Définit la gravité du message
* @param $sévérité
* @retour nul
*/
fonction publique setSeverity($severity)
{
$this->gravité = $gravité ;
}
fonction publique getMessage()
{
renvoie $this->message ;
}
fonction publique setMessage($msg)
{
$ce->message = $msg;
}
}
/*
* Compte les messages avec la gravité donnée dans le tableau
* de messages.
*
* @param $messages Un tableau de ResultMessage
* @return int Nombre de messages avec une gravité « Erreur »
*/
fonction countErrors($messages)
{
$matchingCount = 0 ;
foreach($messages en $m) {
if ($m->getSeverity() == "Erreur") {
$matchingCount++;
}
}
renvoie $matchingCount ;
}
$messages = array(new ResultMessage("Erreur", "Ceci est une erreur !"),
new ResultMessage("Avertissement", "Ceci est un avertissement !"),
new ResultMessage("Erreur", "Ceci est une autre erreur !"));
$errs = countErrors($messages);
echo("Il y a des erreurs " . $errs . " dans le résultat.n"
?＞
Gestion des erreurs
En règle générale, si vous souhaitez écrire des applications robustes, suivez la règle des 80/20 pour la gestion des erreurs : 80 % de votre code est utilisé pour gérer les exceptions et la validation, et 20 % de votre code est utilisé pour faire le travail proprement dit. Cela se fait souvent lors du codage de la logique de base (happy-path) d’un programme. Cela signifie écrire du code qui fonctionne sous le capot, que toutes les données sont disponibles et que toutes les conditions sont comme prévu. Un tel code peut être fragile pendant le cycle de vie de l'application. À l’autre extrême, il faut beaucoup de temps pour écrire du code dans des conditions que vous n’avez jamais rencontrées auparavant.
Cette habitude vous oblige à écrire suffisamment de code de gestion des erreurs, plutôt que d'écrire du code pour gérer toutes les erreurs, de sorte que le code ne se termine jamais.
Mauvaises habitudes : aucune gestion des erreurs Le code
du listing 7 démontre deux mauvaises habitudes. Premièrement, les paramètres d’entrée ne sont pas vérifiés, même si l’on sait que les paramètres de certains états provoqueront des exceptions dans la méthode. Deuxièmement, le code appelle une méthode qui peut lever une exception mais ne la gère pas. Lorsqu'un problème survient, l'auteur du code ou la personne qui gère le code ne peut que deviner la source du problème.
Listing 7. Mauvaise habitude : ne pas gérer les conditions d'erreur
<?php
// Récupère le nom réel du
fonction convertDayOfWeekToName ($ jour)
{
$dayNames = tableau(
"Dimanche",
"Lundi",
"Mardi",
"Mercredi",
"Jeudi",
"Vendredi",
"Samedi");
return $dayNames[$day];
}
echo("Le nom du jour 0 est : " . convertDayOfWeekToName(0) . "n");
echo("Le nom du 10ème jour est : " . convertDayOfWeekToName(10) . "n");
echo("Le nom du jour 'orange' est : " . convertDayOfWeekToName('orange') . "n")
;
Bonne pratique : gestion des exceptions
Le listing 8 montre le lancement et la gestion des exceptions de manière significative. Une gestion supplémentaire des erreurs rend non seulement le code plus robuste, mais améliore également la lisibilité du code, le rendant plus facile à comprendre. La façon dont les exceptions sont gérées est une bonne indication de l'intention de l'auteur original lors de l'écriture de la méthode.
Listing 8. Bonne pratique : gestion des exceptions
<?php
/**
* Il s'agit de l'exception levée si le jour de la semaine n'est pas valide.
* @auteur nagood
*
*/
class InvalidDayOfWeekException extends Exception { }
class InvalidDayFormatException extends Exception { }
/**
* Obtient le nom du jour étant donné le jour de la semaine.
* renvoie une erreur si la valeur fournie est hors plage.
*
* @param $jour
* @return type_inconnu
*/
fonction convertDayOfWeekToName ($ jour)
{
si (! is_numeric($jour)) {
throw new InvalidDayFormatException('La valeur '' . $day . '' est un ' .
'format invalide pour un jour de la semaine.');
}
if (($jour ＞ 6) || ($jour ＜ 0)) {
throw new InvalidDayOfWeekException('Le numéro du jour '' . $day . '' est un ' .
'jour de la semaine invalide. Attendu 0-6.');
}
$dayNames = tableau(
"Dimanche",
"Lundi",
"Mardi",
"Mercredi",
"Jeudi",
"Vendredi",
"Samedi");
return $dayNames[$day];
}
Le
nom du jour 0 est : " . convertDayOfWeekToName(0) . "n");
echo("Le nom du 10ème jour est : " . convertDayOfWeekToName(10) . "n");
} catch (InvalidDayOfWeekException $e) {
echo ("Erreur rencontrée lors de la tentative de conversion de la valeur : " . $e->getMessage() . "n");
}
essayer {
echo("Le nom du jour 'orange' est : " . convertDayOfWeekToName('orange') . "n");
} catch (InvalidDayFormatException $e) {
echo ("Erreur rencontrée lors de la tentative de conversion de la valeur : " . $e->getMessage() . "n");
}
?>
Bien que la vérification des paramètres soit une confirmation - si vous exigez que les paramètres soient dans un certain état, cela sera utile aux utilisateurs de la méthode - vous devez les vérifier et lancer des exceptions significatives :
◆ Gérer les exceptions aussi précisément que possible. qui surviennent sont étroitement liés.
◆Gestion dédiée de chaque exception.
N'utilisez pas le copier-coller.
Vous pouvez copier-coller du code ailleurs dans votre éditeur de code, mais cela présente des avantages et des inconvénients. La bonne nouvelle est que copier du code à partir d’un exemple ou d’un modèle peut éviter de nombreuses erreurs. L’inconvénient est que cela conduit facilement à de nombreuses méthodes de programmation similaires.
Veillez à ne pas copier et coller du code d'une partie de l'application à une autre. Si c'est votre cas, arrêtez cette mauvaise habitude et envisagez de réécrire ce code pour qu'il soit réutilisable. De manière générale, placer le code au même endroit facilite sa maintenance ultérieure car il ne doit être modifié qu'à un seul endroit.
Mauvaises habitudes : des extraits de code similaires
dans le listing 9 montrent plusieurs méthodes presque identiques, mais avec des valeurs différentes. Il existe des outils qui peuvent aider à trouver du code copié et collé (voir Ressources).
Listing 9. Mauvaises habitudes : extraits de code similaires
<?php
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Error"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countErrors($messages)
{
$matchingCount = 0 ;
foreach($messages en $m) {
if ($m->getSeverity() == "Erreur") {
$matchingCount++;
}
}
renvoie $matchingCount ;
}
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Warning"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countWarnings ($ messages)
{
$matchingCount = 0 ;
foreach($messages en $m) {
if ($m->getSeverity() == "Avertissement") {
$matchingCount++;
}
}
renvoie $matchingCount ;
}
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Information"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countInformation ($ messages)
{
$matchingCount = 0 ;
foreach($messages en $m) {
if ($m->getSeverity() == "Informations") {
$matchingCount++;
}
}
renvoie $matchingCount ;
}
$messages = array(new ResultMessage("Erreur", "Ceci est une erreur !"),
new ResultMessage("Avertissement", "Ceci est un avertissement !"),
new ResultMessage("Erreur", "Ceci est une autre erreur !"));
$errs = countErrors($messages);
echo("Il y a des erreurs " . $errs . " dans le résultat.n");
?>
Bonne pratique : fonctions réutilisables avec paramètres
Le listing 10 montre le code modifié, qui place le code copié dans une méthode. Une autre méthode a également été modifiée et délègue désormais des tâches à la nouvelle méthode. Construire une approche commune prend du temps à concevoir, et cela vous permet de vous arrêter et de réfléchir, plutôt que de copier et coller instinctivement. Mais le temps investi dans une approche commune sera payant lorsque des changements seront nécessaires.
Listing 10. Bonne pratique : fonctions réutilisables avec paramètres
<?php
/*
* Compte les messages avec la gravité donnée dans le tableau
* de messages.
*
* @param $messages Un tableau de ResultMessage
* @return int Nombre de messages correspondant à $withSeverity
*/
fonction countMessages($messages, $withSeverity)
{
$matchingCount = 0 ;
foreach($messages en $m) {
if ($m->getSeverity() == $withSeverity) {
$matchingCount++;
}
}
renvoie $matchingCount ;
}
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Error"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countErrors($messages)
{
return countMessages($messages, "Erreurs");
}
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Warning"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countWarnings ($ messages)
{
return countMessages($messages, "Avertissement");
}
/**
* Compte le nombre de messages trouvés dans le tableau de
* ResultMessage avec la valeur getSeverity() de "Warning"
*
* @param $messages Un tableau de ResultMessage
* @return type_inconnu
*/
fonction countInformation ($ messages)
{
return countMessages($messages, "Information");
}
$messages = array(new ResultMessage("Erreur", "Ceci est une erreur !"),
new ResultMessage("Avertissement", "Ceci est un avertissement !"),
new ResultMessage("Erreur", "Ceci est une autre erreur !"));
$errs = countErrors($messages);
echo("Il y a des erreurs " . $errs . " dans le result.n" );
＞
Conclusion
Si vous développez les bonnes habitudes évoquées dans cet article lors de l'écriture de code PHP, vous être capable de créer un code facile à lire, à comprendre et à maintenir. Un code maintenable construit de cette manière réduira le risque de débogage, de correction et d’extension du code.
L'utilisation de bons noms et de méthodes plus courtes améliore la lisibilité du code. Le but de commenter le code est de faciliter la compréhension et l’expansion du code. La gestion appropriée des erreurs rend votre code plus robuste. Enfin, arrêtez d'utiliser le copier-coller pour garder votre code propre et améliorer la réutilisabilité.