Avantages et inconvénients du reformatage forcé de code

Je travaille actuellement dans un endroit qui cherche à forcer les développeurs à utiliser un formateur de code automatisé lors de l'enregistrement du contrôle de version. Je cherche des avis de développeurs sur les avantages et les inconvénients de faire cela ... comment vous pensez que cela aiderait ou gênerait les développeurs. Mon cas spécifique concerne Java / JSP, mais je pense que la question pourrait s'appliquer à n'importe quel langage.

Je pense qu'il est très important de le faire. Voici pourquoi:

• Il fait en sorte que vos différences de contrôle de source affichent uniquement les modifications de code réelles, et éliminent presque tout "bruit de diff" en raison des espaces blancs et d'autres choix de mise en forme insignifiants
• Cela rend tous les codes plus similaires, de sorte que les développeurs sont plus à l'aise pour associer et partager les bases de code

Si vous le faites, je recommanderais à tout le monde d'archiver tout le code, puis une personne effectue un reformatage sur toute la base de code, puis l'archive à nouveau afin qu'il y ait un ensemble de modifications "géant" pour le formatage (que tout le monde peut ignorer), mais après cela, tous les diffs sont de véritables diffs de code.

Si vous le faites petit à petit, vous mélangerez de vrais changements de code avec des changements de formatage et les choses deviendront inutilement désordonnées dans le pays de changement.

Je vais jeter ma propre réponse ici car les gens semblent seulement ajouter des avantages. Ce que je considère comme des inconvénients sont:

• Élimine la possibilité de faire «mieux» que le formateur automatique ... il annulera votre formatage plus propre. Un exemple de ceci serait des déclarations de paramètres basées sur des colonnes, des listes d'ajouts discrets d'objets, etc.
• Crée une résistance aux conventions de style changeantes car celles-ci vont maintenant créer de grands changements de différences trompeuses.
• Supprime la possibilité de faire tout formatage «spécial» où un autre format rendrait le code plus lisible.
• Il vous lie à l'utilisation d'IDE qui prennent en charge exactement les fonctionnalités de reformatage dont vous avez besoin. Dans un autre IDE, il manque l'une des options dont vous avez besoin, cela causera au moins quelques problèmes.
• Il devient problématique de partager un référentiel de code accessible en écriture avec un groupe externe à moins qu'ils n'utilisent exactement les mêmes conventions de format que votre groupe (ils le feront généralement, mais pas toujours).
• Il y aura toujours des exceptions où un format légèrement différent est probablement plus propre que le style prescrit. La conversion automatique peut donc souvent masquer l'intention de certains blocs de code, ce qui est tout aussi efficace que d'ajouter un défaut au code.

En termes simples, un ensemble de conventions non automatisées définit des exigences minimales de style / lisibilité, où les conventions automatisées fixent un minimum et un maximum.

Je me souviens avoir regardé VB (version 5 peut-être) et trouvé l'une des choses les plus ennuyeuses à ce sujet, c'était qu'il reformaterait de force mon code et supprimerait des choses au-delà de sa mise en forme de base.

Je trouve que la mise en forme forcée du code est excellente. Il permet à un développeur de parcourir l'intégralité du corpus de code sans que ses yeux ne rebondissent partout. La mise en place de cette norme aide également les développeurs novices à rompre avec les mauvaises habitudes.

Le principal inconvénient est de perdre le formatage personnalisé là où cela compte vraiment.

Imaginez un contrôle de santé mentale typique if () qui échouera si l'une des conditions spécifiques est présente mais non remplie ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Ceci est lisible grâce à une indentation raisonnable suivant la structure logique des conditions.

Maintenant, votre outil automatisé n'a aucune idée de la séparation logique des différentes conditions en lignes connexes. Il ne voit aucune raison pour laquelle chaque groupe de 3-4 conditions sur une ligne et divise la condition suivante en deux. Ou il le divisera, une expression de comparaison par ligne. Cela peut même sembler plus joli à l'écran, mais la logique sera perdue.

J'ai ajouté une réponse avec des inconvénients, et je vais également apporter ce que je considère comme un gros avantage.

Lorsque vous utilisez un reformatage de code automatisé lors de la validation, cela ouvre en fait la possibilité de variations de préférences personnelles sans l'effet habituel d'infliger vos préférences aux autres. Vous pouvez avoir votre code au format IDE selon une norme commune lors de la validation, mais vous l'afficher dans votre format préféré sans affecter les autres.

Pour moi, c'est presque le Saint Graal du codage basé sur les conventions ... vous obtenez les avantages d'un format de code commun, tout en permettant aux préférences personnelles d'être prises en charge sans conflits.

Cela dépend de vos besoins, mais certaines contraintes sont très utiles, par exemple, chaque if () doit être suivi d'accolades, car il est assez facile d'obtenir une telle erreur si vous refactorisez.

Considérez ce cas:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Si vous voulez maintenant ajouter une journalisation au cas if, vous pourriez accidentellement écrire:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

Et soudain, votre méthode revient toujours foo.

Edit: ce n'est pas sur la mise en forme automatique mais plutôt sur la vérification du style. Désolé si cette réponse était également hors sujet. :)

Cela aide grandement à uniformiser le code dans l'entreprise, et grâce à cela, vous produisez généralement une structure plus facilement compréhensible et beaucoup plus facile à maintenir pour votre produit.

Eh bien, les avantages sont les mêmes que tout formatter de code, comme la standardisation du code, sémantique entre les développeurs, etc. Les seuls inconvénients possibles que je vois est le manque d'un oeil humain après la mise en forme, d'ajouter quelques exceptions, etc.
Donc , je suppose qu'il vaut mieux considérer un formateur IDE au lieu d'un formateur de temps d'enregistrement.

D'après mon expérience, c'est une bonne chose. Sans celui-ci, les comparaisons de code montrent souvent un désordre de formatage des espaces blancs et peuvent masquer les modifications de code réelles. D'après mon expérience, jouer avec le formatage de quelqu'un n'est pas le péché qu'il est censé être, en particulier avec les avantages potentiels de la cohérence au sein de l'équipe.