dans Programmation 101
3 secrets derrière un code propre
Je réitère, encore et toujours… Coder est un art. Imaginez-vous à peindre une toile. Vous commencez alors par une esquisse au crayon, puis vous utilisez une technique précise dans chaque coup de pinceau. Tout comme le code, la beauté est dans les détails. Mais il faut faire attention de ne pas tout gâcher 😉
Aujourd’hui, je vous présente 3 secrets derrière un code propre. Je vous invite à ajouter les vôtres dans les commentaires!
1. Ne commentez pas votre code
Ceci ne s’applique pas si vous développez une API qui sera utilisée par d’autres développeurs. Par exemple : un framework, une facade, un module, etc..
Pourquoi?
Une application peut vite devenir volumineuse. Chaque commentaire doit être entretenu au même titre que le code pour éviter d’en avoir un qui induit en erreur. Le code ne ment jamais, mais les commentaires parfois.
Comment?
Lorsque vous écrivez un commentaire, vous être en train de dire : « Ce bout de code-là n’est pas clair. ». Ceci arrive régulièrement devant une intruction conditionnelle. Sortez les conditions d’un if ou d’un while dès qu’elles sont complexes ( && , || , etc.) dans une méthode privée ou une classe utilitaire.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// Password and email provided must match with the user's if (credentials.emailAddress == userFound.emailAddress && credentials.passwordHash == userFound.passwordHash) { // Do somthing... } // VS if (credentialsMatchUserFound(credentials, userFound)) { // Do something... } function credentialsMatchUserFound(credentials, userFound) { return credentials.emailAddress == userFound.emailAddress && credentials.passwordHash == userFound.passwordHash; } |
Retenez-vous un peu aussi…
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
/** * This class is the representation of a user. */ class User { private String firstName; /** * Returns the first name of the user * @return The first name */ public String getFirstName() { return this.firstName; } } |
Et surtout, avant de mettre un commentaire, posez-vous la question : Qu’est-ce que je peux changer à mon code qui remplacerait ce commentaire?
2. Limitez vos fonctions à 5 instructions
Pourquoi?
Si une fonction fait plus de 5 instructions, il y a de fortes chance qu’elle ne respecte pas le principe de reponsabilité unique (voir SOLID).
Comment?
Tous les environnements de développement modernes ont un outil de refactorisation (extract to method, Martin Fowler) qui vous permettra de créer des fonctions rapidement avec un raccourci clavier. Apprenez-le! Dès que vous sentez le besoin d’isoler une section de code avec des retours de chariot (ou un commentaire ;)), vous devriez trouver une façon de sortir ce code dans une fonction.
3. Définissez vos standards de programmation
Pourquoi?
Mis à part le fait que de voir du code formatté différemment dans un même projet peut faire saigner des yeux, les standards de programmation sont au développeurs ce que les lois sont à la société. Lorsqu’on travaille sur un projet, on y travaille en équipe. Alors autant visuellement grâce au formatage qu’architecturalement parlant grâce à la conception, le code doit sembler venir d’une seule personne (morale) : votre équipe.
Comment?
En équipe, rencontrez-vous et discutez-en. Le résultat doit être documenté à un endroit facile d’accès rapidement pour tous les membres de l’équipe. Puisque j’ai déjà écrit à ce sujet, je vous invite à lire mon article pour vous donner des pistes.
Conclusion
Si j’avais à résumer ces 4 points en une seule expression : Entendez-vous en équipe et rammassez-vous au fur et à mesure. Ne laissez-pas trainer de commentaires, des fonctions trop longues ou de définissez vos standards en équipe.
Avez-vous un secret =^-^= ?
Commentaires
3 commentaires
Salut Sylvain,
bien content que tu aborde ce sujet et amplement ok avec toi sur les secrets 2 et 3. Sur le 1 en revanche, j’ai, si j’ose dire, un commentaire 🙂
Il est bien sur possible de produire du code qui s’auto-documente mais c’est le constat est là: c’est souvent raté. Dans mon métier de consultant, je suis constamment obligé de me taper la lecture de milliers de lignes de code indigentes et de faire des enquêtes à la Sherlock Holmes juste pour essayer d’avoir une idée de l’infrastructure dans laquelle je travaille.
J’en ris encore (un peu) mais je me rappelle avoir travaillé pour un labo pharma sur une application en Perl avec des centaines de modules et le seul commentaire, c’était le courriel du PostDoc créateur de la chose et il était plus la.
Récemment, sur une application en WPF, 65 bibliothèque de classes, une cinquantaine d’écran, j’ai trouvé des commentaires!!! Au dessus de la déclaration des membres statiques, un génie a écrit: Variables statiques….
Bon, ceci étant,, le turn-over dans les équipes et le manque criant de leadership technique des responsables est à mon humble avis pas du tout étranger à ces situations que je ne suis pas seul à rencontrer, j’en suis sûr.
Pour finir, je tiens à dire que je ne suis pas un maniaque de la doc et des commentaires mais un minimum s’impose.
J’espère qu’on reviendra sur là-dessus car c’est un aspect négligé du travail de développeur.
A+
Phil
Salut Philippe,
Ah! Les commentaires dans le code 😅 le principe est relativement simple, mais le gens oublient souvent une étape très importante dans le développement : le refactoring. Je ne parle pas de refaire un truc qui a déjà été fait, mais bien de retoucher son code dès qu’il fonctionne. Une fois que le code est fonctionnel, il faut le rendre plus propre. C’est pas parce que ça marche que c’est comme ça qu’il faut faire, et le fait de se challenger à retirer les commentaires est bon pour atteindre ce but qu’est de produire un code maintenable et facile à faire évoluer. Par contre, je te l’accorde à 100%, c’est impossible à faire sans une bonne connaissance des bases.
En ce sens, je t’invite à lire et partager celui-ci si ce n’est déjà fait 😊 http://blog.ezoqc.com/5-exemples-faciles-pour-comprendre-les-principes-solid/
Merci pour le lien. Je n’avais pas vu cet article. Excellent rappel. Avec les design patterns, c’est la base.
Laisser un commentaire