Il y a des moyens plus simple d’y arriver avec un linter type blake.
Je ne connais pas. Une recherche rapide m'oriente vers linter black pour Python. Ma connaissance sur le sujet est très limitée mais il y a peu de linters qui critiquent les noms de variables/fonctions. Les linters ne sont pas tous aussi bons dans tous les langages.
Personnellement je me fou de savoir comment le code a était écrit. Que mon collègue applique TDD, TCR, qu’il ai fait une méditation avant, qu’il code dans un autre langage et transpile vers le notre ou utilise un LLM. Il y a son nom sur le commit, il doit avoir un bon niveau de confiance en ce qu’il soumet.
Je ne partage pas cette facon d'aborder les choses, surtout pour des jeunes lorsque la relecture est aussi un moyen de transmettre des connaissances (dans les deux sens). Je peux apprendre de celui qui a écrit le code s'il y a des choses que je ne connaissais pas et je peux transmettre si mes remarques sont constructives. Alors oui, la reclecture de code, ce n'est pas toujours un échange constructif pendant lequel on peut apprendre, c'est souvent plus simplement pour améliorer le code et ne pas laisser d'erreur. Concernant la dernière phrase, je préfère un jeune développeur qui doute de lui qu'un jeune trop sûr de lui, je suis convaincu que l'un progressera plus vite que l'autre.
En fait je trouve que ça demande de plus de travail à la relecture parce qu’avant tu avais des indices plus flagrant là où maintenant c’est plus subtil de repérer des problèmes qui des fois existaient déjà.
C'était tout mon argument, si les problèmes détectés lors de la relecture de code sont grossiers, tu perds un peu ton temps. Certains problèmes grossiers doivent pouvoir être détectés avec linter, si la relecture consiste à trouver des problèmes qui pourraient être remontés par un linter ou un autre outil d'analyse statique, je pense que la relecture perd son intérêt. La relecture de code pour trouver des problèmes subtiles me parait très pertinente.
[^] # Re: Gain de temps ?
Posté par nico4nicolas . En réponse au journal Je lis du code généré. Évalué à 3.
Je ne connais pas. Une recherche rapide m'oriente vers linter black pour Python. Ma connaissance sur le sujet est très limitée mais il y a peu de linters qui critiquent les noms de variables/fonctions. Les linters ne sont pas tous aussi bons dans tous les langages.
Je ne partage pas cette facon d'aborder les choses, surtout pour des jeunes lorsque la relecture est aussi un moyen de transmettre des connaissances (dans les deux sens). Je peux apprendre de celui qui a écrit le code s'il y a des choses que je ne connaissais pas et je peux transmettre si mes remarques sont constructives. Alors oui, la reclecture de code, ce n'est pas toujours un échange constructif pendant lequel on peut apprendre, c'est souvent plus simplement pour améliorer le code et ne pas laisser d'erreur. Concernant la dernière phrase, je préfère un jeune développeur qui doute de lui qu'un jeune trop sûr de lui, je suis convaincu que l'un progressera plus vite que l'autre.
C'était tout mon argument, si les problèmes détectés lors de la relecture de code sont grossiers, tu perds un peu ton temps. Certains problèmes grossiers doivent pouvoir être détectés avec linter, si la relecture consiste à trouver des problèmes qui pourraient être remontés par un linter ou un autre outil d'analyse statique, je pense que la relecture perd son intérêt. La relecture de code pour trouver des problèmes subtiles me parait très pertinente.