Quelques règles simples permettent d’avoir un bon code, c’est à dire un code clair, compréhensible, qui tiendra dans le temps et qui sera sécurisé.

Bonnes pratiques

Bien évidemment, je vous conseille de lire un peu tous les articles de ce blog (pas en une seule fois!) pour trouver des pistes et des idées qui assureront la pérennité de votre jeu web. Toutefois, je vais aujourd’hui synthétiser certains éléments qui vous permettront d’avoir un “bon code”: clair, concis, pérenne, et sécurisé.

Langage et philosophie

Respectez la philosophie du langage que vous avez choisi: n’allez pas essayer d’appliquer des méthodes orientées objet à du SQL, et inversement. Acceptez la différence entre typage statique et typage dynamique: n’essayez pas de plier l’un à l’autre car vous ne récolterez que les inconvénients des deux. Evitez de tomber dans le travers de certains Frameworks, qui veulent tout faire dans le même langage car celui-ci ne sera alors adapté à rien du tout.

Se comprendre et comprendre les autres

Fixez et respectez vos conventions de code (comme les conventions de nommage), en reprenant des conventions existantes (évitez de refaire les vôtres), que vous codiez seul ou en équipe. Respectez les architectures existantes, même si vous les jugez obsolètes. Ne sortez pas des sentiers battus tracés par votre équipe (ou par votre passé) sans procéder à une mise à niveau complète du projet (gérer plusieurs architectures dans un seul projet est bien pire que gérer une seule architecture, un peu vieillotte).

Abstraction

Inutile de faire le code le plus abstrait possible pour montrer combien vous êtes intellectuellement fort: soyez pragmatique et basique. Le copier-coller n’est pas malsain en soi: utilisez-le si deux éléments de code sont, par hasard, similaires voire identiques. Bannissez-le et préférez l’abstraction si ces deux éléments sont obligatoirement et sémantiquement liés.

Des commentaires rares mais utiles

Un commentaire doit être succinct, précis, descriptif, non-redondant. Les algorithmes doivent être auto-explicite, donc inutile de commenter ce qu’ils font. Ajoutez une ligne de commentaire si besoin, mais sans plus. Les commentaires multi-lignes ne devraient servir qu’à détailler une architecture interne. Ne paraphrasez jamais le code, mais donnez-en le but. Ne mettez de la PHPDoc (ou assimilé) que pour les méthodes complexes: la PHPDoc ne doit pas juste redire/paraphraser le nom de la méthode et de ses paramètres. Indiquez à quoi sert la classe, si besoin. Enfin, ne gardez pas de code commentez: utilisez un outil de versionning.

Classe, méthode, fonction

Une fonction/méthode/classe doit se restreindre à un périmètre exclusif et bien délimité. Le flou est l’ennemi d’un bon code, et les connexions de pont (“je vais mettre ça [bugfix/feature] là, même si c’est pas sa place, parce que c’est pratique”) sont à bannir. Appliquez le loose coupling (chaque classe en connait le moins possible sur les autres). Faites du East oriented quand c’est pratique et utile (pas partout, sauf si c’est la structure de base de votre langage).

Configurations

Ne hardcodez rien, et isolez les configurations dans des fichiers/classes/tables de BDD dédiées. Renouvelez régulièrement les informations d’accès (credentials) qu’ils peuvent contenir. Limitez les droits au strict minimum (ayez un utilisateur de BDD “root” pour vos mises en production, et créez un utilisateur “Read/write only” que vous utiliserez dans les codes de votre jeu).

Dépréciation

N’utilisez rien de déprécié dans vos codes. Si un élément sur lequel votre code repose vient à être déprécié, faites la mise à niveau rapidement. Evitez de casser les signatures publiques de vos propres codes car cela mènera à de gros refactorings. Quand vous-même dépréciez un élément, supprimez-le immédiatement, à moins que d’autres projets qui ne sont pas à vous reposent dessus Mettez directement vos propres projets à jour (tant que c’est frais dans votre tête) et informez les autres projets de cette dépréciation, pour qu’ils fassent la mise à niveau rapidement (fournissez une procédure de mise à niveau si possible).

Tests

Les tests et débogages doivent être réalisés en continu, et non en toute fin de projet.

Environnement

Utilisez et maîtrisez vos outils de développement (IDE), de débogage (ie: XDebug) et d’analyse (ie: SonarQube). N’hésitez pas à en intégrer de nouveaux à votre stack de développement, mais uniquement s’ils répondent à un réel besoin à la mesure de la lourdeur amené par ces nouveaux outils.