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

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.

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.

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

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'.

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.

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.

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.

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.

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.

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!

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.

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?

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.

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.

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.

Les guides de style facilitent également l’analyse programmatique du code à diverses fins d’analyse.

Google a publié un article intitulé "Recherche de dettes de construction: expériences de gestion de la dette technique chez Google" .

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.

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.