Serait-ce une mauvaise idée d'exécuter périodiquement des formateurs de code sur un référentiel?
Je pense à créer un travail cron qui extrait le code, y exécute des formateurs de code et, si quelque chose a changé, valide les modifications et les repousse.
La plupart des projets qui utilisent des formats automatiques les mettent dans un crochet git, mais le faire automatiquement toutes les quelques heures éliminerait la charge pour chaque développeur d'installer le crochet git.
J'encouragerais toujours tout le monde à écrire du code propre et bien formaté, et peut-être que je pourrais demander au système de cingler automatiquement les développeurs lorsque le code qu'ils ont écrit est reformaté, afin qu'ils sachent quoi faire à l'avenir.
Ça a l'air sympa, mais je préférerais que des personnes soient responsables de la modification des codes, pas des bots.
De plus, vous voulez vous assurer que ces changements 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 la fonctionnalité, 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 vraiment facile pour tout le monde dans l'équipe d'appliquer la mise en forme automatique du code selon la norme de votre équipe directement dans votre éditeur ou IDE, au fichier de code source actuel (ou à certaines parties de celui-ci) ). Cela permet aux membres de votre équipe de mieux contrôler comment et quand le formatage a lieu, laissez-les inspecter le code avant qu'il ne soit validé dans la forme finale 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 une différente, alors votre approche pourrait être la deuxième meilleure solution, tant que l'équipe la prend en charge. Cependant, je vous recommande d'installer des mesures de sécurité supplémentaires, comme les versions nocturnes et les tests automatisés qui sont exécutés après chaque modification automatique de code.
C'est une mauvaise idée, non seulement parce qu'elle décourage les gens d'écrire du code décent, mais aussi parce que le reformatage apparaîtra comme des changements de code 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 de 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'à des mois plus tard.
J'aurais tendance à croire que c'est une bonne idée (pour exécuter automatiquement les formateurs de code), mais c'est juste mon opinion.
Je ne les exécuterai pas périodiquement, mais si possible avant la validation du contrôle de version.
Avec git , un hook pré-commit faire cela serait utile. Dans de nombreux projets C ou C++ construits avec certains Makefile , j'ajoute une cible indent (qui exécute convenablement les formateurs de code comme indent ou astyle ) et attendez des contributeurs qu'ils exécutent make indent régulièrement. BTW, vous pouvez même ajouter des règles make pour vous assurer que les hooks git ont été installés (ou pour les installer).
Mais vraiment, c'est plus un problème social qu'un problème technique. Vous voulez que votre équipe valide un code propre et bien formaté, et c'est une règle sociale de votre projet. (Il n'y a pas toujours de réponse technique à chaque problème social).
Le contrôle de version est principalement un outil pour faciliter la communication entre les développeurs humains (y compris vous-même dans quelques mois). Votre logiciel n'a pas besoin de VC ou de formatage, mais votre équipe en a besoin.
BTW, différentes communautés et différents langages de programmation ont des vues différentes sur le formatage du code. Par exemple, Go n'a qu'un seul style de formatage de code, mais C ou C++ en ont beaucoup.
Je pense que c'est une mauvaise idée. Beaucoup de réponses ont déjà couvert qu'il souille l'histoire en rendant difficile de déterminer qui a réellement ajouté une ligne et qu'il encourage les gens à simplement commettre ce que et le format-bot s'en chargera.
Une meilleure approche serait d'incorporer un vérificateur de format dans votre outil de construction. (Dans Java il y a Checkstyle ) Ensuite, ne permettez aux gens de fusionner leurs branches vers la branche principale que si la construction réussit (y compris le formatage).
Si vous autorisez les gens à s'engager directement dans la branche principale (comme dans Subversion par exemple), vous devrez toujours vous assurer que tout le monde a la discipline de valider uniquement le code formaté (ou que le serveur n'accepte les validations qu'une fois certaines vérifications effectuées) ).
En général, je pense que c'est une mauvaise idée. En principe, c'est une idée valable, mais elle peut être problématique en réalité. Le fait que le formateur de code casse votre code est une possibilité réelle, et il suffit d'une seule mise en forme pour que vos développeurs répondent avec une hostilité (probablement justifiée) (par exemple "Votre formateur de code moche a interrompu la construction, désactivez-le maintenant! ").
Dans la même veine que la recommandation de @ BasileStarynkevitch, nous utilisons des hooks post-réception git côté serveur pour envoyer des "emails de conseil" sur le style de code.
Si je pousse un commit qui contient des violations de style, le serveur git Origin m'enverra un e-mail qui m'informera que j'ai violé les directives de style et recommande que je corrige mon code. Cependant, il ne l'impose pas car il peut y avoir des raisons valables de casser le style de la maison (les longues chaînes dépassant la limite de longueur de ligne, par exemple).
S'il s'agit d'un problème systémique qui nuit à la base de code, il est peut-être temps de commencer à soulever des problèmes de style de code dans les revues de code. Un mauvais style de code 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 utile d'encourager les gens à corriger les défauts esthétiques et stylistiques au fur et à mesure qu'ils les trouvent. Nous avons un message de validation standard "Cosmétique". pour les correctifs de style de code que les autres développeurs connaissent ne contiennent pas de changements de rupture.
Comme le dit @DocBrown, 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 s'exécutera lors de l'enregistrement des fichiers de code, ce qui signifie que le code de mauvais style ne devrait même jamais entrer 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 sonne bien, mais le résultat pourrait encore être horrible.
Vous aurez des conflits de fusion lorsque vous tirerez une branche suivie, du moins je crains que ce soit le cas, mais je peux me tromper.
Je ne veux pas le tester en ce moment au travail, mais vous devriez l'essayer vous-même.
En fait, vous pouvez simplement vérifier un commit récent. Créez une nouvelle branche, engagez quelque chose de mesquin, choisissez ou fusionnez sans aucun autocommit.
Ensuite, exécutez votre script, tirez et si votre résultat est un horrible gâchis de fusion, vous ne devriez certainement pas le faire, à la lumière du jour.
Au lieu de cela, vous pouvez potentiellement le mettre dans une version nocturne ou une version hebdomadaire.
Mais même une soirée pourrait être une mauvaise idée.
Vous pouvez soit l'exécuter chaque semaine, lorsque vous êtes sûr qu'aucun conflit de fusion ne se produira car tout est terminé le lundi.
Sinon, exécutez-le 1-2 fois par an pendant les 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 que faire un script de configuration qui crée automatiquement le référentiel git et définit les crochets pour le projet serait mieux.
Ou vous pouvez inclure le script de configuration du hook dans un dossier pour vos développeurs dans le projet et simplement l'archiver dans git lui-même.
Quelque chose que je n'ai pas vu mentionné 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 que 99% du temps a du sens. Les humains doivent faire cet appel. Dans ces cas, le formatage automatique du code finirait par rendre les choses moins lisibles.
C’est une idée affreuse.
Si l'un de mes collègues développeurs apportait des modifications gratuites aux fichiers source, il ne passerait pas un examen de code. Cela rend la vie plus difficile pour tout le monde. Changez le code qui doit être changé, rien d'autre. Des changements inutiles conduisent à des conflits de fusion, ce qui peut entraîner des erreurs et créer simplement un travail inutile.
Si vous voulez le faire régulièrement, c'est affreux.
Et puis il y a la question du type de changements que le formateur de code fait. J'utilise le formatage automatique dans mon éditeur, cela fonctionne assez 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à de cela, vous n'améliorerez pas 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. Quelque chose comme cela serait probablement suggéré par le type de développeur "grammer-nazi" (orthographe intentionnelle) qui veut imposer son style à tout le monde. Attendez-vous à un retour de bâton et attendez-vous à ce que les développeurs flexibles et normalement faciles à poser leurs pieds.
Vous ne mentionnez pas le VCS que vous utilisez, mais en fonction de cela, une autre option consiste à avoir un crochet 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 envoyée, puis compare le fichier formaté à la version envoyée. S'ils diffèrent, le développeur n'a pas utilisé la mise en forme correcte et le serveur peut rejeter le Push. Cela forcerait vos développeurs à uniquement pousser le code avec le formatage souhaité, les encourageant ainsi à écrire du code propre depuis le début, cela rendrait les développeurs responsables d'avoir testé le code correctement formaté et soulagerait 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 Git 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 blâmez-vous pour comprendre ce qui se passe. Si vous travaillez sur quelque chose de nouveau et n'avez pas à maintenir la compatibilité descendante, l'historique ne joue généralement pas un rôle important.
Cette idée est similaire à certaines autres réponses, mais je ne peux pas commenter mes suggestions.
Une option consiste à définir un alias (ou hook, ou autre) pour la fonction de validation, qui exécute le formateur de code sur le code à valider avant qu'il ne soit validé.
Cela pourrait avoir 2 (ou plus) résultats:
1) Montrez à l'utilisateur les modifications proposées et demandez son approbation pour appliquer et valider les modifications.
2) Ignorez les modifications proposées et validez 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 (selon la façon dont vous voulez pousser ces normes de codage) est de demander au système de vous envoyer un rapport quelconque lorsque l'option 2 est sélectionnée.
Cela peut être un bon équilibre entre la vérification automatique de tout le code comme vous le souhaitez, tout en permettant aux développeurs de s'adapter à leurs besoins. Il permet également l'option de ne pas "rejeter automatiquement" le code avec des différences de formatage comme mentionné dans d'autres réponses. Avec le "J'ai examiné et approuvé les corrections de formatage automatiques; commit 'option, il conserve toujours la responsabilité personnelle pour chaque travail de développeur et ne dérange pas avec VCS.
Je ne le ferai pas sur le référentiel mais je le ferai lors de la sauvegarde si l'outil le supporte. Eclipse en est un et en plus je ferais le nettoyage du code y compris le tri.
La partie Nice est qu'elle fait partie du projet, donc chaque développeur l'obtiendra pour son projet.
Comme un bonus supplémentaire, les fusions seraient considérablement simplifiées car les choses ne sauteront pas.
Les révisions de code empêcheront toute erreur.
Un autre endroit où je le ferais est de l'intégrer à la construction. Dans mon cas, je pense que les versions de maven reformateront le XML et nettoieront les fichiers pom et reformateront le code.
De cette façon, lorsque les développeurs sont prêts à pousser, tout sera nettoyé pour leur demande d'extraction.