Devenez un meilleur développeur grâce aux bonnes pratiques

Cet article est libre d'accès pour tous grâce à ceux qui soutiennent notre blog indépendant.

Ces dernières semaines, j'ai passé pas mal de temps à lire et étudier des articles de blogs, des projets github, des ebooks à la recherche de bonnes pratiques.

J'ai toujours été attiré par les principes de code qui peuvent m'aider à faire du "Beau Code". Faire en sorte que je sois fier de montrer mon code à d'autres développeurs, que je ne m'arrache pas les cheveux lorsque je dois reprendre un projet codé il y a deux mois, que les devs passant après moi ne souhaitent pas ma mort et que mon code soit tellement beau que l'on puisse le photographier.

J'ai cherché principalement en swift, javascript et php mais les principes de code, les bonnes pratiques ne sont pas cloisonnées à un langage. On peut parfaitement les appliquer à tous les langages de programmation.

On va donc se faire un petit résumé de ce que j'ai pu retenir de tous ces articles.

DRY Approach

Ce principe est simple et semble même logique, mais il y a trop de cas où les développeurs ne l'appliquent pas.

DRY ou Don't Repeat Yourself, comme son nom l'indique, consiste à éviter au maximum de se répéter dans son code. C’est-à-dire, travailler avec des objets, des fonctions afin de factoriser le code et ne pas le répéter.

Il n'y a rien de pire lors de la modification d'une application que de devoir appliquer la même modification, le même copier-coller, une dizaine voire une centaine de fois.

Indenter son code

Je suppose que tout le monde ici indente son code... Mais saviez-vous qu'il y a de bonnes pratiques pour l'indentation de vos fichiers ?

Tout d'abord ne jamais travailler avec plusieurs types de tabulations dans un même projet. Si vous êtes plusieurs développeurs à bosser sur le même projet, concertez-vous et mettez-vous d'accord.

Préférez le standard de votre langage. Certains langages ne fonctionnent qu'avec des espaces, d'autres qu'avec des tabulations, et d'autres encore sont très sensibles à ce sujet (ils en ont besoin pour la compréhension du code par le compilateur).

Personnellement, je préfère toujours les espaces aux tabulations lorsque les règles précédentes ne s'applique pas.

En bref, choisissez un type d'indentation, paramétrez le dans votre IDE et n'y touchez plus.

Mettre des commentaires partout

On ne répètera jamais assez aux développeurs de commenter leur code. Pourtant ils sont toujours contents de retrouver un code expliqué plusieurs mois après son écriture.

Vous pouvez même établir avec vos collègues une sorte de "convention" pour l'écriture de vos commentaires. Si tout le monde utilise le même format pour ses commentaires, il sera plus facile de comprendre les commentaires de ses collègue lorsque l'on reprendra le code en urgence pour un hotfix.

Utilisez un système de commentaires documentés compréhensibles par votre IDE tel que phpDocs ou Swift-flavored Markdown. Votre IDE pourra ainsi vous indiquer l'utilité et la méthode d'utilisation d'une fonction quelque soit l'endroit où celle-ci est utilisée.

Évitez de vous répéter dans vos commentaires et choisissez bien l'endroit où vous mettez vos informations. Et surtout, veillez à ce que vos commentaires soient utiles pour les autres.

Utiliser une convention de nommage

Utiliser une convention de nommage pour vos variables, vos objets et tout élément de votre projet peut vous épargner une énorme perte de temps.

Et puis quoi de plus frustrant que de ne pas retrouver une fonction ou une variable parce que son nom n'a pas le même format que les autres ? Là aussi si vous travaillez à plusieurs il va falloir vous entendre !

Vous pouvez même aller plus loin en décidant d'appliquer l'Ubiquitous Language

Appliquer le principe de substitution de Liskov

Appliquez ce principe vous évitera de nombreuses prises de tête et de longues séances d'épilation capillaire. Il est simple :

si S est un sous-type de T, alors tout objet de type T peut être remplacé par un objet de type S sans altérer les propriétés désirables du programme concerné.

En bref, tout objet doit pouvoir être remplacé par un de ses enfants sans entrainer de régression ou d'incompatibilité.

Utiliser des constantes

La plupart des langages permettent de choisir entre variables et constantes pour stocker nos valeurs. Une bonne pratique est de toujours choisir une constante lorsque cela est possible.

Je vois deux avantages à cela : cela rend votre code plus sûr et plus facile à déboguer, les constantes améliorent les performances de votre application.

Suivre un workflow de versionning

Ce principe s'applique surtout aux projets collaboratifs. Pour ce genre de projets on utilise souvent un système de versionning comme Git. Et, pour l'avoir testé, lorsque tout le monde l'utilise à sa sauce, notre repository peu très vite devenir un gros bordel.

La solution à ce problème est de définir un workflow en équipe et de faire en sorte que tout le monde s'y tienne. Lorsque tout le monde travaille de la même façon il devient plus simple pour chacun de s'y retrouver dans le méandre des versions.

Un des workflows Git que je préfère et préconise est Gitflow de nvie.

Ne pas réinventer la roue

On reconnait souvent les développeurs débutants dans une technologie par leur méconnaissance des méthodes des librairies standard.

Ils vont souvent réécrire des fonctions déjà présentes dans la librairie standard. Et généralement ils vont moins bien le faire.

Par exemple, une des questions les plus souvent posée sur les forums PHP est "comment vérifier une adresse email ?". La réponse sera souvent une belle expression régulière.

Mais pourquoi s'embêter à trouver une regex qui doit pouvoir vous dire si la chaine entrée par l'utilisateur est bien une adresse mail (regex qui doit donc prendre en compte des milliers de combinaisons) alors qu'il suffirait d'une fonction de la bibliothèque standard :

filter_var($email, FILTER_VALIDATE_EMAIL)

Essayer de ne pas utiliser else

Utiliser la structure de if...else semble logique dans beaucoup de cas, mais lorsque plusieurs conditions s'imbriquent la lecture du code devient très difficile.

Par exemple :

public function addThreeInts($first, $second, $third) {
    if (is_int($first)) {
        if (is_int($second)) {
            if (is_int($third)) {
                $sum = $first + $second + $third;
            } else {
                return null;
            }
        } else {
            return null;
        }
    } else {
        return null;
    }

    return $sum;
}
public function addThreeInts($first, $second, $third) {
    if (!is_int($first)) {
        return null;
    }

    if (!is_int($second)) {
        return null;
    }

    if (!is_int($third)) {
        return null;
    }

    return $first + $second + $third;
}

C'est un exemple tiré du site www.airpair.com

Vous avouerez que le deuxième exemple est beaucoup plus facile à lire que le premier... Pourtant, ils font tous les deux la même chose.

Rejoins 250+ développeurs de notre liste de diffusion et sois reçois les articles directement dans ta boite mail.

S'inscrire à la newsletter

Aucun spam. Désabonnes-toi en un seul clic à tout moment.

Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.