Mettre en place des standards de cohérence de code et une chose, le faire bien en est une autre !
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Du code impeccable écrit partout pareil, ça donne envie, non ? Et pourtant, l’idée s’avère bien plus risquée qu’elle n’y parait.
Derniers commentaires :
Mathieu Barberot
il y a plus de 2 ans - modifié il y a plus de 2 ans
Globalement d'accord.
J'aurais quand même tendance à poser un .editorconfig d'office dans n'importe quel projet pour les conventions les plus basiques : encodage des fichiers, espaces/tabulations, cr/lf en fin de ligne...
C'est supporté par tous les éditeurs, ça ne mange pas de pain et ça évite bien des problèmes (je pense à toi, le caractère de fin de ligne différent selon l'OS et aussi à toi fichier YAML qui ne supporte pas les tabulations).
Pour les aspects plus avancés, je recommanderais les conventions officielles (s'il y en a) et de n'en diverger qu'exceptionnellement : un nouvel arrivant aura déjà bien assez de sujets qui nécessitent une réadaptation.
J'aurais quand même tendance à poser un .editorconfig d'office dans n'importe quel projet pour les conventions les plus basiques : encodage des fichiers, espaces/tabulations, cr/lf en fin de ligne...
C'est supporté par tous les éditeurs, ça ne mange pas de pain et ça évite bien des problèmes (je pense à toi, le caractère de fin de ligne différent selon l'OS et aussi à toi fichier YAML qui ne supporte pas les tabulations).
Pour les aspects plus avancés, je recommanderais les conventions officielles (s'il y en a) et de n'en diverger qu'exceptionnellement : un nouvel arrivant aura déjà bien assez de sujets qui nécessitent une réadaptation.
Marc Bouvier
il y a plus d'un an
Je rajoute aussi un `.gitattributes` pour forcer les fins de ligne automatiquement via git.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
La duplication de code est sans aucun doute la pire pratique. Pourtant, il y a des situations où elle est primordiale pour écrire un programme stable.
Derniers commentaires :
Julien Sere
il y a plus de 2 ans
Article très intéressant, personnellement, l'injonction du DRY a été un frein pendant longtemps pour moi sur l'adoption de modèle en couche ou l'on va séparer strictement les entités persistante des objets domaine ou des adapteurs qui se ressemble souvent beaucoup
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Sur l'échelle des mauvaises pratiques, la duplication de code doit être au sommet. On va voir comment l'affronter en allant la chercher à la source.
Derniers commentaires :
Nicolas Coquelet
il y a plus de 2 ans
La duplication de code n'est pas tjrs associée à une mauvaise pratique et le DDD, cf l'article du dessous, y voit même certaines qualités.
Pour reciter Cyrille Martraire, voici un podcast ou il expose les limites de DRY dans une approche DDD www.cafe-craft.fr/29
Pour reciter Cyrille Martraire, voici un podcast ou il expose les limites de DRY dans une approche DDD www.cafe-craft.fr/29
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
José Paumard nous présente une sélection commentée des livres qu'il aime bien.
Derniers commentaires :
Jo Jo
il y a presque 3 ans - modifié il y a presque 3 ans
Toujours intéressant de voir les lectures des uns et des autres. Quand il y a des livres qui ressortent souvent, c'est un bon indicateur pour axer ses futures lectures ;) Sinon sur sa chaîne j'ai beaucoup aimé la série de vidéos sur les principes SOLID et design patterns qu'il a fait. C'est très bien expliqué (je crois que ça avait déjà été partagé ici ?) .
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Aujourd'hui, je vais te montrer les pires bouts de code que j’ai jamais vus. Des sataneries qu'il ne faut surtout pas produire !
Derniers commentaires :
Benoit GANTAUME
il y a presque 3 ans
Salut,
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Marc Tourneux
il y a presque 3 ans
Salut,
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.