12 principes pour garder un code propre
Attention, cet article a été déplacé dans les archives, donc le contenu peut ne plus être à jour. A vous de voir 🙂
Je suis tombé hier soir sur un excellent article de Smashing Magazine intitulé « 12 Principles For Keeping Your Code Clean« .
Ce sont 12 étapes assez simples pour avoir un code propre et réutilisable / exploitable par d’autres webmasters / intégrateurs / etc. Voici une adaptation en français, pour ceux qui n’auraient pas le temps de se plonger dans l’article original.
1. Choisissez un Doctype STRICT
On ne va pas revenir sur la guerre ancestrale entre HTML 4.01 et xHTML 1.0. Les deux possèdent une version stricte, vous obligeant à rédiger du code correct.
2. Utilisez des caractères encodés comme &
Pour commencer, assurez-vous d’utiliser un charset UTF-8
Ensuite, assurez vous que les caractères comme & soient bien écrits » & « .
De même pour les lettres accentuées, comme é : » é » ou à : » à »
3. Indentez correctement votre code
Ok, l’indentation n’a -quasiment- aucune influence sur le rendu final de la page, mais le gain en lisibilité est tel que ça vaut carrément le coup. La procédure standard veut que vous indentiez d’une tabulation, ou de quelques espaces, quand vous ouvrez un nouvel élément enfant de l’élément au dessus. Puis ensuite, de revenir d’une tabulation en arrière lors de la fermeture de cet élément.
Evidemment, rien d’obligatoire ni de figé. Ce qui est le plus lisible, et le plus simple à interprêter sera le meilleur 🙂
4. Gardez vos CSS et Javascript hors du fichier.
Les balises <style />, <script />, et autres attributs style= » » devraient être réduits au minimum, et leur contenant externalisé. En effet, il est plus simple d’appeler une seule feuille de style, que d’en maintenir une par page. De même pour les scripts. Certains navigateurs bien réglés les garderont en cache, évitant ainsi des téléchargements inutiles.
5. Organisez correctement vos balises
Un élément de type « inline » doit être dans un élément de type « block ».
Vous voulez faire un lien sur le titre de votre site ?
Ecrivez le comme ceci :
Darklg Blog
Et non comme ça :
Darklg Blog
6. Eliminez les DIV inutiles.
Gardez ça en tête : Une flopée de DIV ne vaut pas mieux qu’un design en tableau.
Il est possible de styliser un h1, un ul, ou la plupart des éléments de type block aussi bien qu’un DIV.
7. Choisissez de meilleurs conventions de noms
Ok, c’est sûrement très facile de nommer cette classe BleuGras, mais qui vous dit que demain, un client ne vous demandera pas de changer tout ça en Vert et Italique ?
Des idées de noms de classes : Entete, Pied, Footer, Navigation, Menu, Sidebar, Principal, Secondaire …
Vous pouvez évidemment les combiner : EnteteNavigation, MenuSecondaire, etc etc …
8. Laissez CSS gérer la typographie.
Il est peut-être plus évident d’écrire UN TEXTE EN CAPITALES, mais il est beaucoup plus simple, pour l’évolutivité de votre code, de faire appel à la propriété CSS text-transform :
h1 {
text-transform : uppercase;
}
9. Ajoutez de la class à votre <body>
Au delà du jeu de mots pourri, il est assez intéressant d’ajouter différents styles, à travers un attribut class, ou id, à l’élément body. Selon le style à adopter sur vos pages, par exemple menu à gauche, ou à droite …
10. Validez votre code.
Si vous développez sous Firefox et que vous avez la » flemme « , ou l’impossibilité de soumettre vos pages au validateur xhtml/css du W3C ( codage hors-ligne, en local, etc ), je vous conseille l’extension HTML Validator, qui vous offrira une validation au fur et à mesure de votre travail.
Attention, on devient vite accro au résultat » 0 erreurs / 0 avertissements « . 🙂
11. Gardez un ordre logique
On ne le dira jamais assez, ordonner vos éléments de manière logique est primordial. Un header doit être dans le haut d’une page, et un footer dans le bas. Certains navigateurs n’affichant pas ( ou mal ) les feuilles de styles vous feraient regretter le choix contraire. Comme le navigateur de votre portable presque-next-gen, par exemple.
12. Faites ce que vous pouvez
Quand on écrit du code depuis le début, c’est plutôt simple d’adapter ces conseils. Malheureusement, c’est beaucoup plus dur lorsqu’on tombe sur un code source datant de l’âge de pierre ( ou plutôt de Frontpage 1.0 ). Si vous êtes bloqués par cette erreur provoquée par une sombre fonctionnalité de WordPress, et qu’il est impossible, ou presque, de modifier, tant pis. L’important, c’est avant tout de vouloir coder proprement, et de faire de son mieux 🙂
Note de Darklg : J’essaie moi même de me tenir à la plupart de ces conseils, mais il y a des fois où, pour telle ou telle raison, ce n’est pas possible. Les conseils que je pourrais rajouter seraient alors :
13. Utilisez le moins de hacks possible
Même s’ils sont souvent des recettes magiques pour réduire des incompatibilités entre navigateurs, les bidouilles sont très rarement évolutives. Pourquoi pas en cas d’énorme blocages, mais évitez les quand vous pouvez 🙂
14. Ne jamais hésiter à demander un avis extérieur.
Que ce soit sur Twitter, sur des Forums, sur des Groupes, auprès de développeurs expérimentés, ou même en soirée codeurs, une question posée au bon endroit, ou un terme recherché intelligemment sur Google, vous sortira souvent d’un immense pétrin.
Cet article est plus une adaptation à ma sauce qu’une véritable traduction. N’hésitez pas à me signaler toute erreur ou toute faute de goût dans les commentaires 🙂
Note : N’hésitez pas à lire cet article de Dame Tartine, qui achèvera de vous convaincre : Code propre et propreté du code
Ah, bah en voila un article intéressant ! Évidemment, un code CSS mal structuré, un code php sans indent, plein de… trucs bizarres peu communs, ça donne pas envie de lire, croyez moi (nous). Même si le code n’est pas visible par l’utilisateur lambda, le mec qui s’y connait un peu va faire un petit ctrl + u et verra votre source. Si il voit un beau code, il sera content, sinon, il se dira qu’il y a beaucoup à faire (surtout si en plus c’est mal codé :p) !
Vive le code propre !
De même pour les lettres accentuées, comme é : ” é ” ou à : ” à ”
Non, non et non ! Ça ne sert à rien d’utiliser UTF-8 sinon…
@Neovov Tu peux développer ?
Pour moi, c’est une technique qui a porté ses fruits, en affichant des textes accentués correctement sur des configs variées.
Il faut utiliser & pour remplacer & parce que & peut être utilisé pour autre chose que pour décrire un esperluette.
Comme d’autres caractères qui ne doivent pas entraver le parseur par exemple.
Dans ton HTML tu décris tes balises avec des < >. Si dans ton texte tu veux mettre ces caractères tu dois utiliser l’équivalent HTML (< et >). Il y a une différence de paradigme, dans un cas tu écris pour le parseur, dans l’autre pour l’utilisateur.
Pour les accents c’est légèrement différent. Je crois qu’aucun accent n’est utilisé par le parseur. On utilise des équivalents HTML pour demander au user-agent de représenter un caractère qui n’est pas disponible dans l’espace de codage sélectionné. Typiquement, lorsqu’on utilise un codage ISO-8859-1 qui ne contient pas le caractère €, il faut utiliser l’équivalent HTML sinon l’user-agent ne sera pas capable de le rendre.
Si tu passes en UTF-8, ton user-agent pourra rendre tous les caractères (unicode sert à unifier toutes les pages de code). Utiliser des équivalents HTML ne sert à rien du coup, sauf à perdre du temps et de la lisibilité.
Les fois où je n’ai pas utilisé d’équivalent HTML pour les caracteres accentués ( dans mon code source, uniquement ) , je me suis vite retrouvé avec des affreux A~ et autres laideurs.
Je l’avoue, ce n’est pas un conseil donné en tant que connaisseur des parseurs et autres subtilités poussées, juste un réflexe que j’ai pris, et qui m’a permis d’esquiver toute incompatibilité 🙂
Dans le même temps, je n’oblige personne à les suivre tous, comme je le rappelle dans la fin de l’article ^^
Mais merci pour la précision 🙂
Si tu te retrouves avec d’autres caractères que tu as tapé c’est que quelque part dans la chaîne d’encodage il y a eu des conversions. Si tu enregistres un fichier HTML dans ton éditeur configuré en UTF-8, et qu’Apache indique au user-agent qu’il reçoit du ISO-8859-1 il va afficher tes caractères UTF-8 avec la page de code ISO.
Donc on a des « caractères » affreux…
L’encodage c’est pas simple, c’est pour ça que j’ai un billet prévu là dessus (une sorte de réécriture de celui là : http://blog.neovov.com/index.php?2007/03/06/143-convertir-un-site-en-utf-8)
Le souci de ton article, c’est qu’on a pas tous un hébergement avec marge de configuration, accès root ssh, et les trucs du genre ^^’
Mon blog est plus grand public que ça, pour ça que je préconise une solution simple.
Et avec une jolie routine de conversion type htmlentities, on ne perd pas de temps, et on passe outre la configuration du serveur 🙂
Tu n’es pas obligé de configurer tout.
Dans mon article j’explique comment configurer pour être par défaut en UTF-8 (les serveurs ont la mauvaise habitude d’être en latin).
Normalement, si tu fais seulement 2 conversions (UTF-8 -> ISO -> UTF-8) tu dois conserver les bons caractères (mais ça reste à vérifier). Donc même sans changer la configuration d’Apache ou de PHP tu peux faire de l’UTF-8, tant que tes données sont en UTF-8 au départ (dans ta BDD) et que tu spécifies qu’elles doivent l’être à l’arrivée (avec un meta et/ou un header HTTP).
PS : Je n’ai pas un serveur dédié hein 😛