Serait-ce une mauvaise idée d'exécuter périodiquement des formateurs de code sur un référentiel?

Je songe à créer un travail cron qui extrait du code, y exécute des formateurs de code et, le cas échéant, validant les modifications et les repoussant.

La plupart des projets qui utilisent autoformatters les mettent dans un crochet Git, mais le faire automatiquement toutes les quelques heures supprime le fardeau pour chaque développeur d'installer le crochet Git.

J'encouragerais néanmoins tout le monde à écrire du code propre et bien formaté. Peut-être que je pourrais faire en sorte que le système envoie automatiquement un ping aux développeurs lorsque le code qu'ils ont écrit est reformaté, afin qu'ils sachent quoi faire à l'avenir.

Cela semble bien, mais je préférerais que des personnes soient responsables des modifications du code, pas des robots.

En outre, vous voulez vous assurer que ces modifications ne cassent rien. Par exemple, nous avons une règle qui classe les propriétés et les méthodes par ordre alphabétique. Cela peut avoir un impact sur les fonctionnalités , par exemple avec l'ordre des données et des méthodes dans les fichiers WSDL des contrats WCF.

J'essaierais plutôt de rendre très facile pour tout le monde dans l'équipe d'appliquer un formatage de code automatique selon le standard de votre équipe directement dans votre éditeur ou IDE , au fichier de code source actuel (ou à une partie de celui-ci). Cela donne aux membres de votre équipe plus de contrôle sur le moment et le formatage, laissez-les inspecter le code avant qu'il ne soit validé dans le formulaire final et testez-le après le formatage , pas avant.

Si tous ou la plupart des membres de votre équipe utilisent le même éditeur, cela ne devrait pas être trop difficile. Si tout le monde en utilise un autre, votre approche pourrait être la deuxième meilleure solution, à condition que l'équipe le soutienne. Toutefois, je vous recommande de prévoir des mesures de sécurité supplémentaires, telles que des versions nocturnes et des tests automatisés exécutés après chaque modification de code automatique.

C'est une mauvaise idée, non seulement parce que cela dissuade les gens d'écrire du code correct, mais aussi parce que le reformatage apparaîtra à mesure que le code change dans votre VCS (vous en utilisez un, j'espère), masquant le flux historique du développement du code. Pire encore, chaque action de formatage du code (en fait chaque modification du code) a la possibilité d'introduire des bogues, qu'ils soient manuels ou automatisés. Ainsi, votre formateur peut maintenant introduire des bogues dans votre code qui ne passeront pas par des révisions de code, des tests unitaires, des tests d'intégration, etc. jusqu'à éventuellement plusieurs mois plus tard.

J'aurais tendance à croire que c'est une bonne idée (d'exécuter automatiquement les formateurs de code), mais ce n'est que mon opinion.

Je ne les exécuterai pas périodiquement, mais si possible avant que le contrôle de version ne soit validé.

Avec git , un hook pré-commit serait utile. Dans de nombreux projets C ou C ++ construits avec un Makefile , j'ajoute une indentcible (qui exécute correctement les formateurs de code tels que indentou astyle) et m'attends à ce que les contributeurs s'exécutent make indentrégulièrement. En passant, vous pouvez même ajouter des makerègles pour vous assurer que les hooks git ont été installés (ou pour les installer).

Mais en réalité, il s’agit plus d’un problème social que technique . Vous voulez que votre équipe commette du code propre et bien formaté, ce qui est une règle sociale de votre projet. (Il n'y a pas toujours de réponse technique à tous les problèmes sociaux).

Le contrôle de version est principalement un outil d'aide à la communication entre développeurs humains (y compris vous-même dans quelques mois). Votre logiciel n'a pas besoin de VC ni de formatage, mais votre équipe en a besoin.

BTW, différentes communautés et différents langages de programmation ont des points de vue différents sur le formatage du code. Par exemple, Go n'a qu'un seul style de formatage de code, mais C ou C ++ en a beaucoup.

Je pense que c'est une mauvaise idée. Beaucoup de réponses déjà évoquées disaient que cela saccage l’histoire en rendant difficile la tâche de déterminer qui a réellement ajouté une ligne et que cela encourage les gens à commettre n'importe quoi et que le bot en forme le gérera.

Une meilleure approche consisterait à incorporer un vérificateur de format dans votre outil de génération. (En Java, il y a Checkstyle ) Ensuite, n'autorisez les personnes à fusionner leurs branches avec la branche principale que si la construction est réussie (y compris le formatage).

Si vous autorisez les utilisateurs à s’engager directement dans la branche principale (comme dans Subversion, par exemple), vous devrez toujours vous assurer que tout le monde a la discipline nécessaire pour n’engager que du code formaté (ou que le serveur n’accepte que les validations une fois que certaines vérifications ont été exécutées. ).

En général, je pense que c'est une mauvaise idée. En principe, c'est une idée valable, mais cela peut être problématique en réalité. Demander au formateur de code de casser votre code est une possibilité réelle, et il ne faut qu'un seul travail de formatage pour que vos développeurs répondent avec une hostilité (probablement justifiée) (par exemple, "Votre mauvais formateur de code a cassé la construction, éteignez-le maintenant! " ).

Dans la même veine que la recommandation de @ BasileStarynkevitch, nous utilisons des points d'ancrage post-réception git côté serveur pour envoyer des "courriels de mise en garde" sur le style de code.

Si j'applique un commit contenant des violations de style, le serveur d'origine git m'enverra un email m'informant que j'ai enfreint les règles de style et me recommande de corriger mon code. Toutefois, cela ne l’applique pas car il peut exister des raisons valables de rompre le style de maison (les longues chaînes dépassant la limite de longueur de ligne, par exemple).

Si c'est un problème systémique qui nuit à la base de code, il est peut-être temps de commencer à évoquer les problèmes de style de code dans les révisions de code. Un style de code médiocre peut masquer des bogues et rendre le code plus difficile à lire. Il peut donc s'agir d'un problème de révision de code valide.

Pour ajouter à l'aspect "problème social" des choses, il peut être intéressant d'encourager les gens à réparer les défauts cosmétiques et stylistiques au fur et à mesure qu'ils les trouvent. Nous avons un message standard de validation "cosmétique". pour les correctifs de style de code que les autres développeurs savent ne pas contenir de modifications radicales.

Comme @DocBrown le dit, une autre option consiste à appliquer le style de code dans votre IDE. Nous utilisons CodeMaid avec Visual Studio pour corriger de nombreuses erreurs de style courantes. Il fonctionnera lors de la sauvegarde des fichiers de code, ce qui signifie qu'un code de style défectueux ne devrait même jamais figurer dans le référentiel ... en théorie :-).

Oui, je pense que c'est une mauvaise idée. Ne vous méprenez pas, la raison de le faire semble bien, mais le résultat pourrait quand même être horrible.

Vous aurez des conflits de fusion lorsque vous tirez une branche suivie, du moins je crains que ce ne soit le cas, mais je peux me tromper.

Je ne veux pas le tester maintenant au travail, mais vous devriez l'essayer vous-même.

En fait, vous pouvez simplement consulter un commit récent. Créez une nouvelle branche, commettez quelque chose de mesquin, choisissez une cerise ou fusionnez sans autocommit.

Ensuite, lancez votre script, tirez et si votre résultat est un désordre de fusion horrible, alors vous devriez absolument ne pas le faire, à la lumière du jour.

Au lieu de cela, vous pouvez potentiellement le placer dans une version nocturne ou hebdomadaire.

Mais même une nuit peut être une mauvaise idée.

Vous pouvez soit l'exécuter chaque semaine, quand vous êtes certain qu'aucun conflit de fusion ne se produira car tout est terminé le lundi.

Sinon, exécutez-le une à deux fois par an en période de vacances, lorsque les conflits de fusion ne se produiront pas.

Mais la solution peut dépendre de votre priorité pour le style de code.

Je pense qu’il serait préférable de créer un script de configuration qui crée automatiquement le référentiel git et définit les points d'ancrage du projet.

Vous pouvez également inclure le script de configuration du hook dans un dossier de vos développeurs dans le projet et le vérifier simplement dans git.

Ce que je n'ai pas vu, c'est le fait qu'il y a parfois des raisons légitimes de ne pas formater quelque chose selon un ensemble de règles. Parfois, la clarté du code est améliorée en allant à l'encontre d'une directive donnée selon laquelle 99% du temps est logique. Les humains doivent faire cet appel. Dans ces cas, le formatage automatique du code rendrait les choses moins lisibles.

C'est une idée terrible.

Si l'un de mes collègues développeurs apportait des modifications gratuites aux fichiers source, il ne passerait pas l'examen du code. Cela rend la vie plus difficile pour tout le monde. Changer le code qui a besoin de changer, rien d'autre. Des modifications inutiles entraînent la fusion de conflits, ce qui peut entraîner des erreurs et créer un travail inutile.

Si vous voulez faire cela régulièrement, c'est affreux.

Et puis il y a la question de quel type de changements le formateur de code apporte. J'utilise le formatage automatique dans mon éditeur, cela fonctionne raisonnablement bien et je peux améliorer les choses lorsque le formatage automatique n'est pas parfait. Si vous utilisez un formateur de code qui va au-delà, vous n'allez pas améliorer le code, vous allez l'aggraver.

Et puis il y a le problème social. Il y a des gens qui veulent forcer tout le monde à utiliser leur style de code, et il y a des gens plus flexibles. Une solution de ce type serait probablement suggérée par le type de développeur "grammer-nazi" (orthographe intentionnelle) qui souhaite imposer son style à tous les autres. Attendez-vous à un retour de bâton et attendez-vous à ce que les développeurs flexibles, généralement faciles à vivre, se mettent en quatre

Vous ne mentionnez pas le VCS que vous utilisez, mais en fonction de cela, une autre option consiste à avoir un raccordement côté serveur. Un VCS comme git le supporte. Vous pouvez installer un crochet côté serveur qui exécute le formateur sur la version poussée, puis compare le fichier formaté à la version poussée. S'ils diffèrent, le développeur n'a pas utilisé le formatage correct et le serveur peut rejeter le push. Cela obligerait vos développeurs à ne pousser que du code avec le formatage souhaité, les incitant ainsi à écrire du code vierge dès le début, ce qui obligerait les développeurs à tester le code correctement formaté et à éviter à vos développeurs d'avoir à installer manuellement un côté client. crochet.

C'est un compromis entre un format de code plus propre et un historique plus précis et plus facile à comprendre. Cela dépend de la nature de votre projet et de la fréquence à laquelle vous plongez dans l’histoire ou la culpabilité pour comprendre ce qui se passe. Si vous travaillez sur quelque chose de nouveau et que vous ne devez pas maintenir une compatibilité ascendante, l'historique ne joue généralement pas un rôle aussi important.

Cette idée est similaire à d'autres réponses, mais je ne peux pas commenter mes suggestions.

Une option consiste à définir un alias (ou un raccord, ou autre) sur la fonction de validation, qui exécute le programme de formatage de code sur le code à engager avant sa validation.

Il pourrait avoir 2 résultats (ou plus):

1) Montrez à l'utilisateur les modifications proposées et demandez leur approbation pour les appliquer et les valider.

2) Ignorer les modifications proposées et valider le code d'origine.

Vous pouvez également ajouter plus de flexibilité à ces options, comme la possibilité de modifier les modifications proposées dans l’option 1. Une autre idée (en fonction de la difficulté à appliquer ces normes de codage) consiste à ce que le système vous envoie un rapport l'option 2 est sélectionnée.

Cela peut constituer un bon équilibre entre la vérification automatique de tout le code que vous voulez, tout en laissant aux développeurs une flexibilité qui leur permet de répondre à leurs besoins. Cela permet également de ne pas «rejeter automatiquement» le code avec les différences de formatage mentionnées dans d'autres réponses. Avec le 'j'ai révisé et approuvé les corrections de formatage automatiques; L'option "commit" conserve toujours la responsabilité personnelle de chaque développeur et ne plaisante pas avec VCS.

Je ne le ferai pas sur le référentiel mais je le ferai sur la sauvegarde si l'outil le permet. Eclipse en est un et je ferais en outre le nettoyage du code, y compris le tri.

La partie intéressante est que cela fait partie du projet et que chaque développeur l’obtiendra pour son projet.

En tant que bonus supplémentaire, les fusions seraient considérablement simplifiées car les choses ne vont pas bouger.

Les révisions de code éviteront les erreurs.

Un autre endroit que je ferais, c’est qu’il fasse partie de la construction. Dans mon cas, il est tel que les constructions maven reformateront le XML, nettoieront les fichiers pom et reformateront le code.

Ainsi, lorsque les développeurs seront prêts à faire pression, tout sera nettoyé pour leur demande d'extraction.