La première bonne pratique à respecter est l’indentation.
Vois l’indentation comme un principe de poupées Russes : chaque élément contenu dans des balises doit avoir une tabulation en amont.
De cette manière, ton code sera plus facilement lisible et tes collègues te remercieront.
Choisis le bon format
Utiliser un format de fichier adapté est la première étape indispensable pour avoir une image optimisée. Le format WEBP est à privilégier autant que possible.
Dimensionner correctement les images
Les dimensions des images intégrées doivent être cohérentes par rapport à leur taille d’affichage dans la page. Sans quoi les navigateurs devront redimensionner eux même les images pendant le chargement.
Utiliser la compression
Réduire la densité de pixels des images permet de limiter leur poids de manière significative. N’hésites pas à utiliser des outils comme TinyPNG pour optimiser tes images.
Tu es un as et tu as crée un algorithme ingénieux qui remplit parfaitement sa fonction ?
Ne sois pas paresseux pour écrire un commentaire sur comment et pourquoi cela fonctionne, peut-être que cela peut paraître inutile et chronophage mais en réalité le gain de temps lorsque tes collègues passeront derrière toi et non négligeable.
Ne laisse pas de fonctions, fichiers et commentaires inutiles. Le prochain développeur devra passer du temps à comprendre ce que ce sont ces ordures. Sois lisible, organisé et compréhensible.
Tu ne gagneras pas grand-chose sur la taille des fichiers, mais cela nuira grandement à la lisibilité.
Bien que certaines abréviations te semblent évidentes, tes collègues eux, peuvent ne pas être en mesure de les comprendre, donc pas de « btnMidLPad2″ par exemple.
Lorsque tu recherches comment créer une fonctionnalité « complexe », le réflexe est de télécharger un plugin qui fera le boulot. Mais dans certains cas, quelques lignes de codes suffisent à remplacer une extension qui peut-être lourde, vulnérable et surtout peu maintenu (cela implique forcément des mises à jours régulières).
Si tu as peur ou si tu bloques sur quelque chose, n’hésites pas à demander conseil à tes pairs, qui seront la pour t’aiguiller.
Moins c’est en dur, mieux on se porte !
L’utilisation des custom field est P.R.I.M.O.R.D.I.A.L.E. Chaque textes, images, liens, blocs, etc … doivent être administrables en Back Office. L’objectif est que le site développé puissent faire son petit bout de chemin sans qu’un développeur ai besoin de mettre ses gros doigts dans le code tous les 2/3 mois. Le temps « perdu » à rendre administrable un champ, on le gagne rapidement par la suite.
Rendre un site administrable ne signifie pas mettre tout son code en Back Office. Éditer un code HTML pour modifier du contenu (par exemple un texte ou une image), ce n’est pas ergonomique, nuit à l’expérience utilisateur, et n’est pas un gage de qualité du code. De plus, les champs « texte » ne sont pas dédiés à cette utilisation et les erreurs de manipulation par le client, ou même les développeurs sont monnaie courante.
Cette méthode est autorisée UNIQUEMENT dans le cas où le site est « temporaire », ou en cas d’extrême urgence si le temps de développement est compté.
Tu n’utilises pas ton couteau pour attraper ta pomme de terre ? Et bien là c’est pareil. Quand un bouton contient une URL, utilise la balise <a> et applique-lui le style d’un bouton. Si le bouton ne contient pas d’URL et lance un action (généralement en JS), utilise la balise <button> ou <input type= »button » />.
PS : Le # est compatibilisé comme une URL.