Imposer le même format de code à tous les développeurs est-il une bonne idée?

88

Nous envisageons d’imposer un seul format de code standard dans notre projet (format automatique avec actions de sauvegarde dans Eclipse). La raison en est qu’il existe actuellement une grande différence entre les formats de code utilisés par plusieurs développeurs (> 10), ce qui complique la tâche d’un développeur pour travailler sur le code d’un autre développeur. Le même fichier Java utilise parfois 3 formats différents.

Je pense donc que l’avantage est clair (lisibilité => productivité) mais serait-ce une bonne idée de l’imposer? Et si non pourquoi?

MISE À JOUR
Nous utilisons tous Eclipse et tout le monde est au courant du plan. La plupart des utilisateurs utilisent déjà un format de code, mais celui-ci n'est pas appliqué car certains préfèrent s'en tenir à leur propre format de code. Pour les raisons susmentionnées, certains préféreraient l’appliquer.

Stijn Geukens
la source
2
Est-ce que tous vos développeurs utilisent Eclipse? leur avez-vous parlé de ce plan? Sans le savoir, il est difficile de répondre à votre question, il faudrait en deviner trop
gnat
9
Cela empêche-t-il réellement un développeur de travailler sur le code d'un autre ou les développeurs sont-ils simplement allergiques à la lecture de code légèrement différent?
Joris Timmermans
27
Lorsque vous utilisez un système de contrôle de code Scource (tel que svn), assurez- vous que les modifications de formatage du code sont effectuées séparément des modifications sémantiques - sinon, il sera difficile de trouver ces modifications sémantiques.
Réintégrer Monica - M. Schröder
4
Je ne suis pas d'accord avec Martin ici, en quelque sorte. Ma règle générale est que si vous effectuez un changement sémantique / logique, vous êtes autorisé à modifier le format des lignes que vous avez modifiées, sinon vous n'êtes pas autorisé à modifier le format des lignes simplement parce que vous en avez envie. Ne colmatez pas votre journal de contrôle de version avec des changements mineurs de reformatage.
Benoît XVI
3
Par contre, si tout le monde utilise le même format, seul le premier s’engage à tout reformater, il sera bouché. Tout le reste ne concernera que les modifications locales apportées, ce qui est acceptable à mon avis.
Jeroen Vannevel

Réponses:

107

Je travaille actuellement à un endroit où un format de code standard est appliqué et le code est automatiquement formaté lors de l'enregistrement du fichier, comme vous allez le faire. En tant que nouveau membre de la société, j'ai constaté que les règles de formatage communes me donnaient un sentiment chaleureux et flou: "Ces gars-là savent ce qu'ils font", je ne pouvais donc pas être plus heureux. ;) Comme remarque parallèle, avec les règles de formatage communes, nous appliquons également certains paramètres d’avertissement du compilateur, assez stricts, dans Eclipse.

Je dirais qu'il y a deux raisons principales pour appliquer un format de code unique dans un projet. Tout d’abord, il s’agit du contrôle de version: lorsque tout le monde met en forme le code de manière identique, toutes les modifications apportées aux fichiers sont garanties. Plus besoin d’ajouter ou de supprimer un espace ici ou là, et encore moins de reformater un fichier entier comme un "effet secondaire" de la modification d’une ligne ou deux.

La deuxième raison est que cela élimine en quelque sorte l'ego des programmeurs. Lorsque tout le monde formate son code de la même manière, vous ne pouvez plus dire aussi facilement qui a écrit quoi. Le code devient de plus en plus une propriété anonyme et commune, de sorte que personne n'a besoin de se sentir mal à l'aise pour changer le code de "quelqu'un d'autre".

Celles-ci étant les principales, il y en a d'autres aussi. Je trouve réconfortant de ne pas avoir à me préoccuper du formatage du code, car Eclipse le fera automatiquement pour moi lors de la sauvegarde. C'est comme une tâche sans souci, comme la rédaction de documents avec LaTeX: il est formaté par la suite et vous n'avez pas à vous en préoccuper lors de la rédaction. J'ai également travaillé dans des projets où chacun a eu son propre style. Ensuite, vous devez penser à des problèmes stupides et sans signification, comme par exemple s'il est correct de modifier le code de quelqu'un d'autre dans votre propre style, ou si vous devez plutôt essayer d'imiter leur style.

Le seul argument contre les paramètres courants de formatage du code que je peux imaginer pour votre cas est qu’il s’agit apparemment d’un projet déjà en cours, ce qui entraînera de nombreuses modifications inutiles dans tous les fichiers, en altérant l’historique des fichiers. Le meilleur scénario est de pouvoir appliquer les paramètres dès le début d'un projet.

Zéro un
la source
20
+100 sur le retrait de l'égo (et de la propriété) des programmeurs de l'équation. Les revendications des programmeurs sur certaines parties du code ne contribuent pas à la productivité car elles entravent le partage des connaissances et signifient qu'il existe un signal, étant donné que tous les programmeurs ne peuvent pas travailler sur le même élément de code.
Marco
Il était difficile de décider quelle réponse accepter, mais j’ai trouvé que celle-ci était la meilleure argumentée et répondait également au mieux à la question.
Stijn Geukens
"Cela signifie qu'il y a un signal, étant donné que tous les programmeurs ne peuvent pas travailler sur le même morceau de code". ne pas travailler dessus / le modifier. Trop de propriété de code partagée peut amener tout le monde à travailler sur la base de code entière et personne ne le maîtrisant vraiment.
Giorgio
J'aurais beaucoup plus de temps pour ce genre de choses si le code était automatiquement formaté à mon style au chargement. Lorsque Roslyn atterrit pour C #, j'espère voir tous les opérations de chargement, de sauvegarde, de gestion des versions, etc., effectuées sur AST au lieu du texte.
Mark Rendle
Des avertissements plus stricts et des erreurs sont une bonne chose.
Christophe Roussy
37

Tous les développeurs de logiciels professionnels préféreront adopter un (bon) standard plutôt que de se lancer dans des guerres évangéliques au détriment du style, pour les raisons mêmes que vous avez décrites.

De nombreux développeurs de logiciels mènent des guerres évangéliques ......

Selon votre position au sein de l'équipe et la dynamique de l'équipe, vous pouvez décider qu'il n'est pas possible de gagner la guerre. Dans ce cas, il vaut peut-être mieux ne pas commencer ...

Mattnz
la source
Tx, je sais très bien ce que tu veux dire
Stijn Geukens
15
Ce n'est pas professionnel de faire la guerre au sujet du formatage du code. Un développeur de logiciel professionnel accomplira tout aussi bien les choses, que son code soit " if( foo )" ou " if (foo)". Si vous avez vraiment besoin de vendre ce type de changement à quelqu'un, vous devez faire appel au fait que ce sont des professionnels. Ils ne peuvent pas répondre ou ils vont paraître anal-rétentif. Si quelqu'un le fait de toute façon, eh bien, j'espère que dans votre intérêt, ils trouveront bientôt un nouvel emploi.
ZeroOne
7
Un développeur professionnel pourrait également écrire du code lisible et être capable de lire le code des autres développeurs professionnels assez facilement, éliminant ainsi le besoin d'une norme étendue. Je crains qu'ici "la norme" ne soit pas un bon remède au mauvais problème (vous ne corrigez pas les développeurs négligés avec une norme de codage).
Joris Timmermans
2
La meilleure façon de contourner la plupart de ces guerres saintes est d’accepter les défauts de langue chaque fois que cela est possible. Oui, cela signifie que votre style de codage variera selon les langues (le code ex C # aura {sur des lignes distinctes. Java les aura sur la ligne précédente, et ce qui sera PascalCased ou camelCased variera); mais chaque source de langue individuelle aura l'air «normale» lorsque vous apporterez de nouveaux développeurs au projet.
Dan Neely
1
@ruakh Regardez des exemples de code MSDN C #, voyez comment Visual Studio reformate C # par défaut: {est sur sa propre ligne. Répétez l'exercice pour Java dans la documentation Oracle et les valeurs par défaut d'Eclipse lors du reformatage du code: {est sur la ligne ci-dessus.
Dan Neely
30

Oui, c’est bien d’avoir un seul style de format de code pour tous les développeurs.

Concevez les formats de style de code et importez-les pour tous les développeurs Eclipse.

Cela aidera lorsque nous utiliserons le mergingcode du système 'Contrôle de version'.

NPKR
la source
5
+1 pour mentionner les outils de fusion et de diff. Il est très difficile d'essayer de repérer les différences entre deux versions d'une base de code lorsque le formatage n'est pas cohérent entre les développeurs.
Pgras
1
+1, je seconde fortement l'argument du système de contrôle de version. (mais c'est principalement à cause des règles d'indentation. Des choses telles que les conventions de nommage n'ont pas autant d'impact.)
BiAiB
Les conventions de dénomination aident lorsque vous devez déterminer quelle méthode s'appelle une méthode dont vous savez qu'elle existe dans une classe.
Dan Neely
1
@Giorgio Il y a en effet des développeurs qui font ça. Tout en mélangeant avec d'autres modifications aussi (par exemple, corrections de bogues critiques). Certaines choses sont envoyées pour nous essayer…
Donal Fellows
1
@Donal Fellows: Vous avez raison. Je suis le principe que chaque caractère que vous tapez dans un fichier source est (1) une erreur potentielle (2) introduit une modification qui rend le code difficile à reconnaître par la suite. Donc, à mon avis, chaque changement devrait être aussi petit que possible. Mais, oui, il y a des développeurs qui changent le code sans trop y penser. Je me demande si un reformatage automatique du code peut résoudre le problème. Je préférerais être propriétaire du code (voir par exemple le point 7 à l' adresse paulgraham.com/head.html ).
Giorgio
16

Qu'est-ce que vous essayez de gagner, comment allez-vous vous en tenir à son application (et au niveau de détail où seront définies vos "règles"), allez-vous essayer de l'appliquer à du code écrit dans différentes langues, allez-vous essayer de l'appliquer rétroactivement au code existant?

  1. une apparence commune à un code peut effectivement aider à rendre le code plus lisible, mais peut également aggraver les choses si elle est fausse. La notation _hUngarian_lpfstr est un bon exemple :)
  2. J'ai vu des "normes de code" imposer le nombre d'espaces entre les blocs de commentaires, l'ordre alphabétique des noms de méthodes et d'autres absurdités. Ne fais pas ça.
  3. Différentes langues ont différentes normes auxquelles sont habitués les utilisateurs expérimentés. Certains imposent même ces normes (pensez à Python, Cobol, Visual Studio impose automatiquement les conventions de renforcement de style C ++ alors que Java utilise le style C par convention, etc.).
  4. ne changez jamais le code existant pour le changer, vous introduisez uniquement de nouveaux problèmes de cette façon. Et cela signifie des sections de code ainsi que des fichiers source entiers. Donc, ne reformatez pas le code existant lorsque quelqu'un modifie une seule ligne dans un fichier de 1 000 lignes.
  5. Les programmeurs expérimentés peuvent être beaucoup plus productifs s’ils ne sont pas obligés de penser la moitié du temps si ce qu’ils écrivent sera "correct" pour le système d’approbation automatique ou pour le relecteur. Ils auront également l’habitude d’écrire du code propre simplement parce que c’est ce qui fonctionne, même s’il existe de petites différences entre leurs styles naturels.



Ainsi, s'il existe de bonnes raisons d'imposer un style et une norme spécifiques, il y a de bonnes raisons de ne pas le faire (trop) strictement.

jwenting
la source
1
1-2-3: C'est Java et le format de code est celui de Sun; il s'agit simplement de formater, donc pas de méthodes de tri ni de noms de variables; 4-5: L’idée serait de formater automatiquement lors de la sauvegarde (actions de sauvegarde Eclipse) afin d’éviter tout travail supplémentaire (vous n’aurez même pas besoin de penser au format lors du codage), mais bien entendu, les fichiers existants seraient également reformatés ( première fois).
Stijn Geukens
1
+1 pour KISS. @Stijn Pourquoi reformater l'ancien code? Appuyez simplement sur lorsque vous devez le modifier.
Erik Reppen
3
En fait, nous prévoyons quelques refactorisations majeures et nous reformaterions tout le code à ce moment-là, car la fusion sera de toute façon presque impossible à cause du refactoring. Si nous ne faisons que reformater sur le changement, nous serons toujours confrontés à des problèmes de fusion en raison du format modifié dans un an.
Stijn Geukens
4
Je suis généralement d'accord avec @StijnGeukens; pas seulement pour des raisons de fusion, mais parce que tout nettoyage de formatage à grande échelle rendra difficile l'historique des modifications d'un outil à blâmer. Si tous vos changements de bruit se situent au même endroit, vous pouvez toujours définir le blâme de manière à ce qu'il commence avant ce point, puis effectuez un deuxième tour avant de s'arrêter avant si vous devez consulter l'historique plus ancien.
Dan Neely
2
vous avez oublié une autre raison, Dan: les modifications de formatage à grande échelle peuvent facilement introduire de nouveaux bogues dans des endroits inattendus.
Jwenting
11

Oui, la cohérence est une bonne idée, pour les raisons que d' autres ont mentionnées .

Je voulais juste ajouter quelques points qui n’ont pas été utilisés ailleurs:

  • Oracle a publié un ensemble de conventions pour Java, qui constituent le standard de facto.
    • Leur utilisation devrait vous aider à éviter les disputes sur le style à suivre.
    • Un grand nombre de bibliothèques publiques et de projets open source ont tendance à utiliser ces conventions. Par conséquent, le formatage devrait vous être familier.
    • Le formateur Eclipse a des règles intégrées pour correspondre à ces conventions, ce qui devrait également aider.
  • Vous voudrez peut-être envisager de créer un point d'ancrage dans la configuration de votre contrôle de code source afin que le code soit automatiquement mis en forme avant d'entrer dans la branche principale.
    • Vous pouvez éviter les batailles avec des programmeurs particulièrement obstinés qui refusent de suivre la norme. Ils peuvent même utiliser leur propre formatage pendant leur travail, ce qui sera normalisé plus tard!
    • Si vous utilisez des paramètres de mise en forme personnalisés (par exemple, de nombreuses personnes ignorent la convention "80 caractères maximum par ligne"), vous ne devez effectuer les modifications qu’à un seul endroit.
vaughandroid
la source
9

J'étais dans une équipe qui a utilisé le plugin Checkstyle . Plutôt que d'utiliser les fonctionnalités prédéfinies, nous avons formé un petit comité de développeurs intéressés. Nous avons débattu de ce qui semblait manquer, de ce qui semblait excessif, et avons mis les choses au clair. Nous avons tous appris quelque chose au cours du processus et avons renforcé les muscles de développement.

(Exemples de décisions: une largeur de 72 caractères, ce qui est trop petit, mais 120, c'est mieux; il est préférable d'utiliser _ALLCAPS pour les finales statiques; imposer l'exit d'une seule fonction est une bonne idée.)

Lorsque nous avons eu des critiques de code, l'une des premières questions était: "L'avez-vous exécuté via Checkstyle?" Le respect des normes de codage était en grande partie automatisé, ce qui a attiré l'attention sur le fait que l'examinateur était difficile. Il était merveilleusement facile de faire en sorte que Checkstyle mette en surbrillance une signature de méthode, clique avec le bouton droit de la souris et modifie une variable en finale. Cela pourrait également corriger les empreintes et les accolades afin que le code de tout le monde ait le même aspect. Manquer une Javadoc pour une fonction publique? Checkstyle marquera la fonction.

(Supprimer l'odeur de code est plus important que le formatage cohérent. C'est un avantage des outils automatisés.)

Je place des outils automatisés comme Checkstyle moins en imposant le même format et plus sur encourager un aspect similaire. Et lorsque vous élevez des chats, un outil automatisé peut vous aider à améliorer vos compétences et à réduire les odeurs de code sans endommager les ego fragiles.

Rajah9
la source
5
Un seul point de sortie? Il y a certains principes de style avec lesquels je ne suis vraiment pas d'accord. (Si plusieurs sorties posent problème, la fonction / méthode est trop longue en premier lieu…)
Donal Fellows
@DonalFellows, Checkstyle nous a fourni un point de référence à partir duquel nous pourrions nous orienter vers les préférences du comité. Il y avait beaucoup d'exclamations de la nature, "Je ne vois pas pourquoi ils ont mis cette norme dans!" Tandis que le PO posait des questions sur la cohérence du formatage, je pense que l'outil automatisé en donne beaucoup plus sans douleur supplémentaire.
rajah9
6

Si vous vous en tenez au même IDE et intégrez des outils de formatage, c'est une bonne idée car vous n'exigez pas trop d'effort. Gardez les règles simples en mettant l’accent sur la lisibilité et non sur la rétention anale . Cela devrait être le bâton de mesure.

Bien qu’une boule de boue toujours formulée soit préférable à une boule de boue, votre temps serait mieux dépensé à la nettoyer au lieu d’être trop pointilleux quant à savoir où vont les crochets. Ne vous laissez pas influencer par le responsable qui a l’impression de faire son travail en comptant les espaces de retrait lors de la révision du code et en s’assurant que les nouvelles pages de couverture figurent bien dans les rapports TPS .

Les préférences personnelles ne sont que cela et améliorent rarement la production: https://stackoverflow.com/questions/249432/whats-the-reasoning-hind-the-different-brace-forms

Si c'est le cas, surmontez-vous et faites quelque chose.

JeffO
la source
6

Je recommande fortement que les humains appliquent le formatage du code et que les infractions mineures soient négligées ou retouchées. Les raisons pour cela sont, brièvement,

  1. La machine se trompe au pire moment possible, et généralement lorsque vous utilisez une nouvelle fonctionnalité de langue. Comment va-t-il gérer les fermetures en Java, etc.? Jalopy a des problèmes avec les énumérations avec les fonctions membres.
  2. Je pense que c'est un fardeau très raisonnable d'imposer au programmeur de produire du code pour l'entreprise qui ressemble à un code d'entreprise. J'ai trouvé utile de mentionner que c'est ainsi que le code est formaté "ici", et non pas comme tout le code devrait être formaté partout. Leur entreprise précédente a peut-être choisi une voie différente, et ce n'est pas grave. Contrairement à la langue vernaculaire, vous souhaitez faire ressortir des expressions spécifiques à votre culture de code.
  3. L'application de la syntaxe de code est préférable avec les révisions de code:
    1. Si le formatage est important, votre organisation sera alors amenée à réviser le code. C'est un avantage énorme.
    2. Si une règle de formatage est enfreinte, un humain peut l'examiner et juger mieux qu'une machine si l'intention est communiquée plus proprement. C'est très rare, mais cela arrive parfois.

En ce qui concerne "lisibilité => productivité", la structure de code (telle que les classes et les fonctions à responsabilité unique) vous achètera beaucoup plus rapidement que le formatage du code. Le formatage du code peut être une aide, mais différents esprits analysent les déclarations différemment - tout le monde ne sera pas "plus productif". J'aimerais revenir sur la structure du code plutôt que sur le formatage, car cela vous incitera également à effectuer des révisions de code et amènera l'équipe à réfléchir au fonctionnement du programme et non à l'apparence d'une boucle.

Je ne suis pas un grand fan de Domain Driven Design, mais c'est un modèle récent qui a une idée TRÈS bien définie quant à la manière dont le code devrait être structuré et les conventions de formatage de code découlent naturellement d'un programme structuré de Domain Driven Design. Encore une fois ... Je n'aime pas le DDD, mais c'est un excellent exemple car il est très bien défini.

Je suppose que le thème de cette réponse est le suivant: Faites des critiques de code et laissez le formatage découler de la culture et sortez du processus de révision.

Sam
la source
Tx, ce n'est pas un mauvais point de vue. Mais là encore, cela représente un travail supplémentaire si, lors de chaque révision, le réviseur doit également vérifier le format.
Stijn Geukens
3
C'est un clic supplémentaire pour appeler une ligne dans quelque chose comme Fisheye, comme "indentation incohérente" ou "accolade ouverte en ligne par elle-même", alors oui, c'est plus que zéro effort. Cependant, si cela prolonge les révisions de code de plus d'une minute, il y a un problème grave. Après une semaine de révision par son équipe de son propre code, ils devraient tous être très rapides à remarquer le "mauvais" code et à le retoucher.
Sam
4

En règle générale, si vous engagez des développeurs raisonnables, il est déconseillé d’imposer un format de code universel. Il est toutefois judicieux d’adopter les directives du code .

Je n'ai jamais vu un ensemble de règles de formatage de code optimisant la lisibilité dans tous les cas. De même, il n'y a pas de règles de grammaire 100% applicables en anglais: notre cerveau n'est tout simplement pas câblé de cette façon. Utilisez donc des instructions, mais donnez aux développeurs la liberté de les remplacer comme bon leur semble.

Cela dit, une règle plus stricte consistant à "suivre la convention de code qui existe déjà dans le fichier / projet" est bonne.

Mais gardez à l'esprit que la mise en forme contribue beaucoup moins à la lisibilité que la simple organisation logique du code. J'ai vu beaucoup de code spaghetti illisible avec un formatage parfait!

Keredson
la source
2

Je ne pense pas qu'il y ait une réponse simple à cela. Ce n'est pas une question oui ou non. Bien que je pense que les conventions de style et de nommage sont importantes dans une certaine mesure, il est également assez facile de perdre trop de temps à y penser. Il est préférable de répondre par l'exemple.

Sur un projet en particulier, il n'y avait aucune convention. Chaque développeur a fait les choses à sa manière. En raison de l’inexpérience relative de cette équipe, passer d’une classe à l’autre était vraiment choquant. Le style posait moins problème que le problème des conventions de dénomination. Un développeur ferait référence à des éléments d'interface utilisateur avec une notation hongroise épouvantable (une pratique ridicule à l'ère des IDE modernes), un autre nommerait les membres privés d'une manière, un autre les nommerait différemment. Tu ne savais jamais ce que tu regardais.

À l'extrême opposé, une équipe a utilisé StyleCop (il s'agissait d'un projet .Net) dans le cadre de son processus de construction. Ce qui est pire, c'est qu'ils ont également utilisé la plupart des règles par défaut. Vous feriez donc quelque chose de tout à fait normal en termes d’espacement des lignes ou de placement des accolades, et la construction en sortirait à cause de cela. Tant de temps a été perdu à juste ajouter des espaces et des lignes, et tout le monde, y compris les mecs qui ont insisté pour utiliser StyleCop, a fini par le faire presque à chaque engagement. C'était une énorme perte de temps et d'argent.

Donc, ce que je veux dire, c'est qu'être inflexible n'est pas la solution, mais être dans le Far West ne l'est pas non plus. La vraie solution consiste à trouver le lieu le plus logique, ce qui, à mon avis, consiste à ne pas utiliser d’outils automatisés pour vérifier des éléments, mais non à rejeter les conventions au vent.

Jeff Putz
la source
2

Mon principal argument contre le style de codage courant est qu'un programmeur expérimenté est habitué à lire son propre style. Vous pouvez entraîner la main à écrire un style spécifique, mais il est presque impossible de former un œil pour comprendre un style que vous détestez. Un programmeur écrit une partie du code une fois, puis le lit encore et encore pendant le développement et le débogage. Si chaque fois qu'il lit son propre code, il a du mal à le comprendre puisqu'il a été obligé de l'écrire dans un style BAD, il sera très malheureux et moins productif. Ceci est de mon expérience.

Je ne connais pas trop Eclipse, mais le formatage automatique lors de la sauvegarde semble une idée horrible. Un développeur doit avoir un contrôle complet sur son code, que le style de code soit imposé ou non. L'opération 'save' ne doit pas changer un seul caractère sans le consentement explicite de l'utilisateur.

Si votre entreprise vend du code source, le style de codage est plus important, mais si vous vendez du code compilé, il est beaucoup moins pertinent.

Espérer que le style de codage rendra le codeur original moins reconnaissable et empêchera les guerres de l'ego, c'est de la connerie dans le meilleur des cas et stupide dans le pire des cas. Les grands programmeurs produiront toujours un code élégant, quel que soit leur style.

Je suis également fortement en faveur de donner à chaque développeur la propriété d'unités de code spécifiques et de laisser tout le monde toucher librement chaque morceau de code. Développer des unités entières dans le code et en être responsable permet au développeur de devenir fier de son travail et de l’empêcher de développer un code de merde sachant que les bogues reviendront le chasser.

Enfin, toute personne qui utilise le style de codage pro suppose toujours que son propre style de codage sera sélectionné et que tous les autres suivront. Imaginez que le style de codage que vous aimez le moins de tous vos codéveloppeurs soit sélectionné en standard. Êtes-vous toujours en faveur de l'imposition d'un style de codage?

Gur
la source
2

Un format pour les gouverner tous ... est-ce vraiment optimal?

C'est comme conduire la voiture de quelqu'un d'autre ...

Bien sûr, vous pouvez monter à bord et conduire n’importe quelle voiture, mais vous serez plus en sécurité, plus confortable et moins susceptible de vous écraser si vous prenez le temps de régler le siège, le volant et les rétroviseurs à VOTRE préférence.

Avec le code, le formatage affecte votre confort de lecture et de compréhension du code. S'il est trop éloigné de ce à quoi vous êtes habitué, cela demandera plus d'effort mental. Est-il nécessaire d'infliger cela aux développeurs?

+1 à tous les avantages mentionnés jusqu'à présent, mais ...

L’application automatique entraîne des coûts qui doivent être pris en compte:

-1 au fait que les formateurs de code ne comprennent pas l'esthétique du formatage du code. Combien de fois avez-vous eu un formateur de code détruire un bloc de commentaires qui était bien aligné dans une forme tabulaire? Combien de fois avez-vous volontairement aligné une expression complexe sur un certain moyen pour augmenter la lisibilité, pour que la mise en forme automatique la modifie en quelque chose qui "suit les règles", mais qui est beaucoup moins lisible?

Il existe parfois des solutions de contournement à ces problèmes, mais les développeurs ont des problèmes plus importants à résoudre que de savoir comment empêcher le formateur automatique de modifier le code.

Ayez des règles de formatage, mais laissez une certaine liberté pour appliquer le bon sens.

swpalmer
la source
2
Je suis absolument d'accord! Les autoformateurs sont stupides.
Łukasz Wiktor
1

Les bons développeurs sont des créatifs, accordez-leur une licence artistique. "Keep it simple" devrait être le mantra des programmeurs. J'ai deux règles:

Règle 1: Indiquez les variables / curseurs / objets / procédures / quels que soient les noms sensibles. Des noms non ambigus qui apportent sens et compréhension à votre code.

Règle 2: utilisez l'indentation pour afficher la structure de votre code.

C'est ça.

Jonesi
la source
1
Pouvez-vous expliquer pourquoi c'est le cas? Comment laisser à chaque développeur une licence artistique (qui diffère d’un développeur à l’autre sur un même projet) donne-t-il une meilleure idée que d’avoir le même format pour tous? Y a-t-il des problèmes que le vôtre résout que l’alternative ne résout pas? Et vice versa?
Ce que j'essaie (et que je ne fais pas), c’est que l’utilisation de noms raisonnables et l’indentation de votre code sont bien plus importantes en ce qui concerne la lisibilité / la maintenabilité que d’autres règles que vous pouvez inventer. Je ne dis pas que chaque membre de l'équipe devrait avoir son propre style, mais que s'ils le font, alors quoi.
Jonesi
Pensez si j'ai un formateur de code dans Eclipse configuré dans un sens et que je reformate toujours mon code ... et que vous en ayez un configuré légèrement différemment ... et nous continuons à modifier le même code. Cette "licence artistique" pose-t-elle des problèmes dans les diffs?
Bien que je comprenne ce que vous dites, je pense qu’un problème avec votre point de vue est que vous avez des styles très différents (remarque, ne vous trompez pas, simplement différent). Cela peut entraîner de réels problèmes et des retards lors de la fusion de ces différents styles.
Daniel Hollinrake
1
Oui, j'ai compris ton point de vue Daniel. Je devrais ajouter une troisième règle: lors de la modification du code existant, adaptez-le au style du code que vous modifiez. C’est ce que je ferais naturellement si je réparais un ancien programme.
Jonesi
0

Pour moi, le principal avantage d'un format commun appliqué automatiquement est qu'il facilite notre suivi des modifications et la révision de notre code. git (et la plupart des autres outils de contrôle de code source) peut afficher les différences des versions précédentes des fichiers. En appliquant un style commun, il minimise les différences de préférence du programmeur.

Kristian H
la source
-1

Ce sont les langues, pas les codes. Nous, les humains, avons plus de 6000 langues, alors nous les traduisons. Donc, si vous voulez que vos "codes" communiquent, vous devrez faire vos ajustements. Vous voyez que les utilisateurs doivent modifier nos formats de données pour ne pas perdre nos données.

vic belleli
la source
-2

Je dirais que ce n'est pas. Une structure / format de code commun au sein d'une équipe est certainement une bonne chose, mais son application automatique ne l'est pas. Cela devrait être fait par des humains, pas par l'ordinateur.

Mes plus gros problèmes avec le concept sont

  1. Si j'écris du code dans un format et qu'il est automatiquement reformaté, quel intérêt y a-t-il à apprendre réellement ce format?
  2. Après ce point précédent, si vous n’apprenez pas le format, le point entier de la mise en forme automatique (pour rendre le code plus facile à lire et à modifier) ​​est complètement perdu. Vous devez encore prendre le temps de comprendre le formatage car vous lisez le code car vous n'avez pas appris ce format
  3. Je pense que ce serait une expérience choquante en tant que développeur d'écrire un cours un jour, de le fermer et de revenir le lendemain pour voir qu'il est complètement différent. Cela signifie que non seulement les autres doivent apprendre votre code, vous devez apprendre votre code.
  4. Cela pourrait également encourager le codage paresseux. Au lieu de pousser le développeur à apprendre le format, ils peuvent écrire n'importe quel format sous le soleil et le résultat sera automatiquement identique à celui que tout le monde souhaite. Cela remonte à # 2 où vous n'apprenez pas le style et ne pouvez toujours pas le lire correctement.

J'aurais peut-être tendance à dire que l'exécution d'un formatage automatique sur un projet entièrement terminé serait une bonne idée. Cela commencerait tous les développeurs sur le même pied pour le projet lorsque vous iriez plus tard à réparer / ajouter des fonctionnalités. Au cours du développement actif, cependant, je pense que c'est un très mauvais choix.

Fondamentalement: confiez à l'employé la responsabilité d'apprendre le style de l'entreprise, ne forcez pas son code à être quelque chose qu'il ne l'est pas.

Josh Janusch
la source
+1: Bons points, même si je ne suis pas sûr qu'ils l'emportent sur les raisons en faveur du reformatage automatisé. Pourquoi les votes négatifs?