Code hérité: formater ou ne pas formater?

Dans mon avis, le formatage du code cohérent améliore la lisibilité. Il n'est clairement pas substitut à un bon code, mais d'autre part, la construction la plus brillante qui est formatée de manière polyvalente ne peut pas non plus être appelée bonne code.

Le problème avec le format automatique pour moi est principalement qu'il perturbe le système de versement. Une conversion ponctuelle de formatage - sans autre changement - peut cependant bien améliorer le flux de travail.

Nous utilisons réellement une formation automatique dans Eclipse et que cela rend souvent mon code moins lisible, par exemple en insérant dans de nombreuses pauses de ligne. Et comme nous avons migré vers une nouvelle version Eclipse, le format n'était pas le même bien que nous utilisions les mêmes paramètres. C'est un énorme inconvénient en combinaison avec un système de contrôle de version. Je préfère le plugin de checkstyle pour obtenir un style de code cohérent.

Mais comme dit, j'utiliserais une autoformatère une fois lorsque vous refactez un fichier.

Le même problème que je peux penser avec l'activation automatique de la mise en forme automatique dans Eclipse, c'est que si vous utilisez le contrôle de la source (vous utilisez le contrôle de la source, non?), le diffs sera massif et il sera peut-être difficile de déchiffrer Qu'est-ce qu'un changement de code réel par rapport à un changement de format.

Cela étant dit, le code bien formaté est essentiel pour écrire un logiciel solide.

Un formatage cohérent du code aide vraiment avec diffusion et tel lors de la soumission de code.

J'ai configuré mes scripts de contrôle source au format automatique au "style house" lors de la poussée et du format automatique sur mon style préféré lors de la tirage, donc tout le monde est heureux.

Je vous recommande de considérer la même chose.

dépend de ce que vous entendez par "désorganisé". Parlons-nous des incohérences stylistiques, ou la structure de classe est-elle un hodge-podge inintelligible? Je suppose que le premier si vous y répondez via une formatrice automatique.

"codage approprié" ne signifie pas nécessairement "cohérent entre les développeurs". Si j'avais mon éditeur défini sur des onglets rigoureux de quatre espaces et que vous avez le choix sur les onglets logiciels à trois espaces, le code que nous travaillons tous les deux va ressembler à un cul. (Et notre responsable de projet devrait probablement vous planter à la fois à la fois à la tête et laissez-nous savoir quelle standard nous devrions utiliser.)

Le formateur automatique est un peu une solution de force brute et est à peu près garantie de transformer occasionnellement quelque chose d'inhabituel mais parfaitement lisible dans un gâchis. Si le code est vraiment autant d'un gâchis, c'est un point de départ raisonnable. Mais une fois que vous avez automatiquement formaté la majeure partie du code préensitant du code préexistant, vous ferez mieux d'établir les conventions de style préféré de l'équipe et de procéder à partir de là.

Je pense que le format de votre code est important. Les exemples fournis mettent en évidence le potentiel d'erreurs idiotes comme celui-là pour se glisser, bien que je voudrais utiliser l'exemple pour discuter de toujours en utilisant les accolades!

Je trouve que vous devez travailler plus fort pour comprendre le code lorsque vous envisagez des fichiers source qui ont une variété de formatage différente. Les modèles de code réguliers facilitent la compréhension de la sémantique car les déclarations sont toutes "au bon endroit".

Je ne suis pas sûr de ce qui était signifié par "codage approprié" car il semble un peu ambigu de ce qui constitue "approprié". Il existe des constructions linguistiques qui ne doivent probablement jamais être utilisées dans des circonstances normales et des anti-motifs d'ingénierie logicielle qui doivent être évités. Si ces choses sont ce que l'on entend par codage approprié, alors que ces choses sont importantes, mais elles ne réfléchissent pas au formatage du document de fichier source.

Il existe des outils pour forcer le formatage de code dans un fichier source en effectuant des violations des défaillances de la construction de formatage. Au début, j'étais sceptique de tels outils car ils semblent un peu draconien, mais j'ai constaté que la structure de l'uniforme du code une véritable productivité augmente.

P.s. Dernière déclaration complètement anecdotique car je n'ai aucune mesure pour le sauvegarder.

Le code de formatage est extrêmement important:

• En conservant le code correctement en retrait, la navigation à travers les fichiers moyens ou volumineux peut être plus facile sur l'utilisateur.
• En gardant un style de codage consistent sur tous les projets, lorsque les personnes se déplacent vers d'autres projets, ils seront plus familiers avec le code. Bien entendu, cela est également lié aux directives de codage, comment nommer des variables, etc. qui doivent également être relativement normalisées dans un terrain d'entente.
• Si vous passez du temps à faire des règles de mise en forme du code appropriées, vous garantissez également que le code peut être visualisé par plus d'utilisateurs (je devais éditer le code à la main dans un texte [Penser Bloc-notes ou Emacs] à la main, malheureusement. En définissant une longueur de ligne à 80 cols ou de sorte qu'il peut aider)
• surtout, en gardant le formatage cohérent, vous pouvez differez deux fichiers beaucoup plus faciles