Share
Deux fois par mois, nous revoyons certains des articles préférés de nos lecteurs au cours de l'histoire de Nettuts.+.
La lisibilité du code est un sujet universel dans le monde de la programmation informatique. C'est l'une des premières choses que nous apprenons en tant que développeurs. Cet article détaille les quinze meilleures pratiques les plus importantes lors de l’écriture de code lisible..
Les environnements de développement intégré (IDE) ont parcouru un long chemin ces dernières années. Cela a rendu les commentaires de votre code plus utiles que jamais. Le respect de certaines normes dans vos commentaires permet à l'EDI et à d'autres outils de les utiliser de différentes manières..
Considérons cet exemple:
Les commentaires que j'ai ajoutés à la définition de fonction peuvent être prévisualisés chaque fois que j'utilise cette fonction, même à partir d'autres fichiers..
Voici un autre exemple où j'appelle une fonction d'une bibliothèque tierce:
Dans ces exemples particuliers, le type de commentaire (ou de documentation) utilisé est basé sur PHPDoc et l'IDE est Aptana..
Je suppose que vous savez déjà que vous devez indenter votre code. Toutefois, il est également intéressant de noter que c’est une bonne idée de conserver un style d’indentation cohérent..
Il y a plus d'une façon d'indenter le code.
fonction foo () if ($ peut-être) do_it_now (); encore(); else abort_mission (); finalize ();
fonction foo () if ($ peut-être) do_it_now (); encore(); else abort_mission (); finalize ();
fonction foo () if ($ peut-être) do_it_now (); encore(); else abort_mission (); finalize ();
J'avais l'habitude de coder dans le style n ° 2 mais je suis récemment passé au n ° 1. Mais ce n'est qu'une question de préférence. Il n'y a pas de "meilleur" style que tout le monde devrait suivre. En fait, le meilleur style est un style cohérent. Si vous faites partie d'une équipe ou si vous contribuez du code à un projet, vous devez suivre le style existant utilisé dans ce projet..
Les styles d'indentation ne sont pas toujours complètement distincts les uns des autres. Parfois, ils mélangent des règles différentes. Par exemple, dans les normes de codage PEAR, le support d’ouverture "" va sur la même ligne que les structures de contrôle, mais elles vont à la ligne suivante après les définitions de fonction.
Style poire:
function foo () // placé sur la ligne suivante if ($ peut-être) // placé sur la même ligne do_it_now (); encore(); else abort_mission (); finalize ();
Notez également qu’ils utilisent quatre espaces au lieu d’onglets pour les indentations..
Voici un article de Wikipedia avec des exemples de styles de retrait différents.
Commenter votre code est fantastique; cependant, il peut être excessif ou simplement tout simplement redondant. Prenons cet exemple:
// récupère le code de pays $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); // si le code pays est US si ($ country_code == 'US') // affiche l'entrée de formulaire pour state echo form_input_state ();
Lorsque le texte est si évident, il n'est vraiment pas productif de le répéter dans les commentaires..
Si vous devez commenter ce code, vous pouvez simplement le combiner sur une seule ligne:
// affichage de la sélection d'état pour les utilisateurs américains $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); if ($ country_code == 'US') echo form_input_state ();
Le plus souvent, certaines tâches nécessitent quelques lignes de code. Il est judicieux de conserver ces tâches dans des blocs de code séparés, avec quelques espaces entre eux..
Voici un exemple simplifié:
Accentsconagua
// obtenir la liste des forums $ forums = array (); $ r = mysql_query ("SELECT id, nom, description FROM forums"); while ($ d = mysql_fetch_assoc ($ r)) $ forums [] = $ d; // charge les modèles load_template ('header'); load_template ('forum_list', $ forums); load_template ('footer'); Ajouter un commentaire au début de chaque bloc de code souligne également la séparation visuelle.
PHP lui-même est parfois coupable de ne pas suivre des schémas de nommage cohérents:
Tout d'abord, les noms devraient avoir des limites de mots. Il y a deux options populaires:
Avoir différentes options crée une situation similaire aux styles d'indentation, comme je l'ai mentionné précédemment. Si un projet existant suit une certaine convention, vous devriez le faire. En outre, certaines plates-formes linguistiques ont tendance à utiliser un certain schéma de nommage. Par exemple, en Java, la plupart du code utilise des noms camelCase, tandis qu'en PHP, la majorité des utilisations sont soulignées.
Ceux-ci peuvent également être mélangés. Certains développeurs préfèrent utiliser des traits de soulignement pour les fonctions procédurales et les noms de classe, mais utilisent camelCase pour les noms de méthode de classe:
classe Foo_Bar fonction publique someDummyMethod () function nom_fonction_procédure_développement ()
Encore une fois, il n'y a pas de "meilleur" style évident. Juste être cohérent.
DRY signifie «ne vous répétez pas». Aussi connu sous le nom de DIE: la duplication est mauvaise.
Le principe dit:
"Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d'un système."
L'objectif de la plupart des applications (ou des ordinateurs en général) est d'automatiser les tâches répétitives. Ce principe devrait être maintenu dans tout le code, même les applications Web. Le même morceau de code ne devrait pas être répété encore et encore.
Par exemple, la plupart des applications Web comportent plusieurs pages. Il est fort probable que ces pages contiennent des éléments communs. Les en-têtes et les pieds de page sont généralement les meilleurs candidats pour cela. Ce n'est pas une bonne idée de garder copier en collant ces en-têtes et pieds de page dans chaque page. Jeffrey Way explique comment créer des modèles dans CodeIgniter..
$ this-> load-> view ('includes / header'); $ this-> load-> view ($ main_content); $ this-> load-> view ('includes / footer'); Trop de niveaux d'imbrication peuvent rendre le code plus difficile à lire et à suivre.
function do_stuff () //? if (is_writable ($ folder)) if ($ fp = fopen ($ chemin_fichier, 'w')) if ($ stuff = get_some_stuff ()) if (fwrite ($ fp, $ stuff)) //? else return false; else return false; else return false; else return false;
Par souci de lisibilité, il est généralement possible d’apporter des modifications à votre code afin de réduire le niveau d’imbrication:
function do_stuff () //? if (! is_writable ($ folder)) return false; if (! $ fp = fopen ($ chemin_fichier, 'w')) return false; if (! $ stuff = get_some_stuff ()) return false; if (fwrite ($ fp, $ stuff)) //? else return false;
Nos yeux sont plus à l'aise lorsque nous lisons des colonnes de texte hautes et étroites. C'est précisément la raison pour laquelle les articles de journaux ressemblent à ceci:
Il est recommandé d’éviter d’écrire de longues lignes de code horizontalement..
// bad $ mon_email-> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Méthodes chaînées') -> set_body ('Un long message') -> envoyer(); // good $ mon_email -> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Méthodes chaînées') -> set_body ('Un message long') -> envoyer(); // bad $ query = "ID de sélection, nom d'utilisateur, prénom, nom de famille, statut FROM utilisateurs LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; // good $ query = "ID de sélection, nom d'utilisateur, prénom, nom de famille, statut FROM utilisateurs LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; De plus, si quelqu'un a l'intention de lire le code à partir d'une fenêtre de terminal, telle que les utilisateurs de Vim, il est judicieux de limiter la longueur de la ligne à environ 80 caractères..
Techniquement, vous pouvez écrire un code d'application complet dans un seul fichier. Mais cela se révélerait être un cauchemar à lire et à maintenir.
Lors de mes premiers projets de programmation, je connaissais l’idée de créer des "fichiers d’inclusion". Cependant, je n'étais même pas encore organisé à distance. J'ai créé un dossier "inc" contenant deux fichiers: db.php et functions.php. Au fur et à mesure que le nombre d'applications augmentait, le fichier de fonctions devenait aussi énorme et inaccessible.
L'une des meilleures approches consiste à utiliser un cadre ou à imiter leur structure de dossiers. Voici à quoi ressemble CodeIgniter:
Normalement, les variables doivent être descriptives et contenir un ou plusieurs mots. Mais cela ne s’applique pas nécessairement aux variables temporaires. Ils peuvent être aussi courts qu'un seul personnage.
Il est recommandé d’utiliser des noms cohérents pour vos variables temporaires ayant le même type de rôle. Voici quelques exemples que j'ai tendance à utiliser dans mon code:
// $ i pour les compteurs de boucles pour ($ i = 0; $ i < 100; $i++) // $j for the nested loop counters for ($j = 0; $j < 100; $j++) // $ret for return variables function foo() $ret['bar'] = get_bar(); $ret['stuff'] = get_stuff(); return $ret; // $k and $v in foreach foreach ($some_array as $k => $ v) // $ q, $ r et $ d pour mysql $ q = "SELECT * FROM table"; $ r = mysql_query ($ q); while ($ d = mysql_fetch_assocr ($ r)) // $ fp pour les pointeurs de fichiers $ fp = fopen ('fichier.txt', 'w'); L'interaction de base de données est une partie importante de la plupart des applications Web. Si vous écrivez des requêtes SQL brutes, il est judicieux de les conserver également lisibles..
Même si les mots spéciaux SQL et les noms de fonctions ne tiennent pas compte de la casse, il est courant de les utiliser pour les distinguer des noms de table et de colonne..
SELECT ID, nom d'utilisateur FROM utilisateur; UPDATE utilisateur SET last_login = NOW () WHERE id = '123' SELECT id, nom d'utilisateur FROM utilisateur u LEFT JOIN us_address ua ON (u.id = ua.user_id) WHERE ua.state = 'NY' GROUP BY u.id ORDER BY Nom d'utilisateur LIMIT 0,20
Ceci est un autre principe qui s'applique à presque tous les langages de programmation dans tous les environnements. Dans le cas du développement Web, les "données" impliquent généralement une sortie HTML.
Lorsque PHP a été lancé pour la première fois il y a de nombreuses années, il était principalement considéré comme un moteur de template. Il était courant d'avoir de gros fichiers HTML avec quelques lignes de code PHP entre les deux. Cependant, les choses ont changé au fil des ans et les sites Web sont devenus de plus en plus dynamiques et fonctionnels. Le code est maintenant une partie importante des applications Web et il n'est plus recommandé de le combiner avec le code HTML..
Vous pouvez soit appliquer le principe à votre application vous-même, soit utiliser un outil tiers (moteurs de modèles, frameworks ou CMS) et suivre leurs conventions..
Frameworks PHP populaires:
Moteurs de modèles populaires:
Systèmes de gestion de contenu populaires
Vous pouvez choisir de ne pas utiliser un moteur de modèle sophistiqué, mais d'utiliser plutôt du PHP en ligne simple dans vos fichiers de modèle. Cela ne viole pas nécessairement la "séparation de code et de données", tant que le code en ligne est directement lié à la sortie et lisible. Dans ce cas, vous devriez envisager d'utiliser la syntaxe alternative pour les structures de contrôle..
Voici un exemple:
Bonjour, Nom d'utilisateur; ?>
|Mon babillard
Titre; ?>
Forums en tant que $ forum):?>id, $ forum-> title)?> (Threads-> count (); ?> discussions)
la description; ?>
Cela vous permet d'éviter beaucoup d'accolades. En outre, le code ressemble à la façon dont le code HTML est structuré et mis en retrait..
La programmation orientée objet peut vous aider à créer du code bien structuré. Mais cela ne signifie pas que vous devez abandonner complètement la programmation procédurale. Créer un mélange des deux styles peut être bon.
Les objets doivent être utilisés pour représenter des données, résidant généralement dans une base de données.
class User public $ username; public $ first_name; public $ last_name; public $ email; fonction publique __construct () //? fonction publique create () //? fonction publique save () //? fonction publique delete () //?
Les fonctions procédurales peuvent être utilisées pour des tâches spécifiques pouvant être effectuées indépendamment.
fonction capitalize ($ string) $ ret = strtoupper ($ string [0]); $ ret. = strtolower (substr ($ string, 1)); return $ ret;
Les projets Open Source sont construits avec la participation de nombreux développeurs. Ces projets doivent maintenir un niveau élevé de lisibilité du code afin que l’équipe puisse travailler ensemble le plus efficacement possible. C'est donc une bonne idée de parcourir le code source de ces projets pour observer ce que font ces développeurs..
Lorsque vous "refactorisez", vous apportez des modifications au code sans modifier aucune de ses fonctionnalités. Vous pouvez penser à cela comme à un "nettoyage", dans le but d'améliorer la lisibilité et la qualité.
Cela n'inclut pas les corrections de bogues ni l'ajout de nouvelles fonctionnalités. Vous pouvez modifier le code que vous avez écrit la veille, alors qu'il est encore frais dans votre tête, afin qu'il soit plus lisible et réutilisable lorsque vous pourrez éventuellement le consulter dans deux mois. Comme le dit la devise: "refactor tôt, refactor souvent".
Vous pouvez appliquer n'importe laquelle des "meilleures pratiques" de lisibilité du code pendant le processus de refactoring.
J'espère que vous avez apprécié cet article! Tout ce que j'ai manqué? Faites le moi savoir via les commentaires. Et si vous souhaitez améliorer votre codage, de nombreux scripts et applications sont disponibles pour vous aider sur Envato Market. Voir ce qui est le plus populaire cette semaine.
