Avantages et inconvénients du reformatage forcé de code


19

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.


Auto-reformatage JSP? Cela inclut le code HTML / XML et le reformatage qui peuvent très facilement casser / modifier la sortie résultante.
edA-qa mort-ora-y

Réponses:


23

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.


1
Mordre la balle sur un changement global est vraiment le meilleur moyen, je suis d'accord; faites-le et personne n'a plus à s'en soucier.
Patrick Hughes

... jusqu'à ce que vous changiez votre convention de style.
Nerdfest

1
@Nerdfest Ensuite, vous appliquez votre nouvelle convention sur tous vos projets en un seul commit. Ce n'est pas grave.
gizmo

2
Votre outil "diff" est nul s'il ne peut pas gérer correctement les changements d'espaces.
edA-qa mort-ora-y

2
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.
edA-qa mort-ora-y

10

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.


Une convention de formatage par rapport à une autre donne rarement un avantage si elle se fait au détriment de la cohérence. Vous vous y habituez. Suivez les conseils de Bohemian et créez une période de grâce pour aider à déterminer les styles de formatage, puis respectez-les. Le changement de format ne doit en aucun cas être pris à la légère.
JeffO

3
@Jeff, je ne pense pas qu'il préconise une mise en forme de code incohérente, mais plutôt une mise en forme de code cohérente difficile à automatiser. Par exemple, de nombreux styles de codage spécifient l'alignement des colonnes de manière esthétique lorsque vous avez plusieurs lignes de données associées ensemble. Cela améliore considérablement la lisibilité, mais il est très difficile d'automatiser les définitions de «esthétique» ou «apparenté». C'est la raison pour laquelle certains formateurs de code autorisent le formatage manuel à remplacer dans certaines circonstances.
Karl Bielefeldt

1
Il est de loin préférable d'avoir un format cohérent 99,9% du temps et de supporter le bit que vous n'aimez pas personnellement, que de supporter une discordance indisciplinée. Je dépend probablement de la discipline avec laquelle l'équipe est responsable de l'équilibre. Si vous vous en tenez aux normes établies pour une langue, tous les éditeurs / IDE décents seront capables de formater de cette façon. Si vous insistez pour sortir des normes, vous aurez des problèmes.
mattnz

3

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.


3

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.


C'est le bordel, mon cerveau de positrons vient de fondre. Tellement d'incohérence avec les espaces autour (et). C'est exactement pourquoi nous avons besoin de machines pour formater le code. Et vous pouvez toujours mettre un commentaire sur une seule ligne avant / après (selon votre convention) pour forcer le regroupement des conditions. Il serait également utile d'expliquer au lecteur les règles commerciales qui sous-tendent ces conditions - dans ces commentaires sur une seule ligne.
Štefan Oravec

@ ŠtefanOravec: exécutez cela via une mise en forme automatique et appliquez ces commentaires. Voyez si c'est plus lisible. Utilisateur de test - toujours. Utilisateurs humains avec des noms d'utilisateur valides. Utilisateurs émulés - uniquement des sources externes. L'email, s'il est présent, doit être valide. Les utilisateurs humains doivent avoir un numéro de téléphone; émulé - ne doit pas. Découvrez comment vos commentaires sur une seule ligne s'alignent sur le code mis en forme automatiquement.
SF.

2

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.


0

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. :)


C'est plus une chose de style de code, pas une chose de formatage. Il existe des outils de construction pour cela.

@Bohemian, vous avez raison, j'ai mal lu la question. L'outil de construction de notre choix est checkstyle btw. :)
Thomas

0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.