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 (formatage automatique avec actions de sauvegarde dans Eclipse). La raison en est qu'il existe actuellement une grande différence dans les formats de code utilisés par plusieurs (> 10) développeurs, ce qui rend plus difficile pour un développeur de 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 d'imposer cela? Et sinon, pourquoi?
MISE À JOUR
Nous utilisons tous Eclipse et tout le monde est au courant du plan. Il y a déjà un format de code utilisé par la plupart mais il n'est pas appliqué car certains préfèrent s'en tenir à leur propre format de code. Pour les raisons ci-dessus, 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, tout comme vous êtes sur le point de le faire. En tant que nouveau membre de la société, j'ai trouvé que les règles de formatage communes me donnaient un sentiment chaleureux et flou que "ces gars-là savent ce qu'ils font", donc je ne pourrais pas être plus heureux. ;) Comme note complémentaire, avec les règles de mise en forme communes, nous appliquons également certains paramètres d'avertissement du compilateur plutôt stricts dans Eclipse, la plupart d'entre eux étant définis sur Erreur, beaucoup étant définis sur Avertissement et presque aucun sur Ignorer.
Je dirais qu'il y a deux raisons principales d'appliquer un format de code unique dans un projet. Il s'agit d'abord du contrôle de version: avec tout le monde formatant le code de manière identique, toutes les modifications dans les fichiers sont garanties d'être significatives. Il ne suffit plus d'ajouter ou de supprimer un espace ici ou là, et encore moins de reformater un fichier entier comme un "effet secondaire" de ne changer qu'une ligne ou deux.
La deuxième raison est que cela élimine en quelque sorte les ego des programmeurs. Avec tout le monde formatant leur code de la même manière, vous ne pouvez plus aussi facilement dire qui a écrit quoi. Le code devient une propriété plus anonyme et commune, donc personne n'a besoin de se sentir mal à l'aise de changer le code de "quelqu'un d'autre".
Ce sont les principales raisons, il y en a aussi d'autres. Je trouve réconfortant de ne pas avoir à me soucier de la mise en forme du code, car Eclipse le fera automatiquement pour moi lorsque j'enregistrerai. C'est sans souci, comme écrire des documents avec LaTeX: il est formaté après et vous n'avez pas à vous en soucier lors de l'écriture. J'ai également travaillé sur des projets où chacun a ses propres styles. Ensuite, vous devez penser à des problèmes stupides et dénués de sens, comme si vous pouvez modifier le code de quelqu'un d'autre dans votre propre style, ou si vous devriez essayer d'imiter leur style à la place.
Le seul argument contre les paramètres de formatage de code courants auquel je peux penser pour votre cas est qu'il s'agit apparemment d'un projet déjà en cours, donc cela entraînera de nombreux changements inutiles dans tous les fichiers, gâchant l'historique des fichiers. Le meilleur scénario est de savoir si vous pouvez commencer à appliquer les paramètres dès le début d'un projet.
Chaque développeur de logiciel professionnel préférera adopter une (bonne) norme plutôt que de se lancer dans des guerres évangéliques pour le style, pour les raisons 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 que gagner la guerre n'est pas possible. Dans ce cas, il est préférable de 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 à tous les développeurs Eclipse.
Cela nous aidera lorsque nous utiliserons le code merging pour le système de "contrôle de version".
Qu'essayez-vous de gagner, à quel point allez-vous faire preuve de rétention anale (et dans le niveau de détail de vos "règles"), allez-vous essayer de l'appliquer sur du code écrit dans différentes langues, allez-vous essayer de l'appliquer rétroactivement sur le code existant?
- une apparence et une sensation communes au code peuvent en effet aider à rendre le code plus lisible, mais peuvent également aggraver les choses si ce n'est pas la bonne apparence. La notation _hUngarian_lpfstr est un excellent exemple :)
- J'ai vu des "normes de code" imposer le nombre d'espaces entre les espaces dans les blocs de commentaires, l'ordre alphabétique des noms de méthode et d'autres bêtises. Ne fais pas ça.
- Différentes langues ont des normes différentes auxquelles les gens sont habitués et qui sont expérimentés dans leur utilisation. Certains imposent même ces normes (pensez que Python, Cobol, Visual Studio impose automatiquement des conventions de contreventement de style C++ tandis que Java utilise le style C par convention, etc. etc.).
- ne modifiez jamais le code existant pour le changer, vous introduisez seulement de nouveaux problèmes de cette façon. Et cela signifie des sections de code ainsi que des fichiers source entiers. Donc, n'allez pas reformater le code existant lorsque quelqu'un change une seule ligne dans un fichier de 1000 lignes.
- les programmeurs expérimentés peuvent être beaucoup plus productifs s’ils n’ont pas à penser la moitié du temps si ce qu’ils écrivent "ira bien" au système d’approbation automatique ou au réviseur. Ils vont également avoir l'habitude d'écrire du code propre simplement parce que c'est ce qui fonctionne, même s'il y a de petites différences entre leurs styles naturels.
Donc, s'il existe de bonnes raisons d'imposer un style et une norme spécifiques, il y a aussi de bonnes raisons de ne pas le faire (trop) strictement.
Oui, la cohérence est une bonne idée, pour des raisons autres ont mentionné .
Je voulais juste ajouter quelques points qui n'ont pas été utilisés ailleurs:
- Oracle a publié n ensemble de conventions pour Java, qui sont la norme 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, donc lorsque vous devez les consulter, la mise en forme doit être familière.
- 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 hook dans votre configuration de contrôle de code source afin que le code soit automatiquement formaté avant d’entrer dans la branche principale.
- Vous pouvez éviter les batailles avec des programmeurs particulièrement têtus qui refusent de suivre la norme. Ils peuvent même utiliser leur propre formatage pendant leur travail, qui sera normalisé plus tard!
- Si vous finissez par utiliser des paramètres de mise en forme personnalisés (par exemple, beaucoup de gens ignorent la convention "max 80 caractères par ligne"), vous n'avez qu'à apporter des modifications au même endroit.
J'étais dans une équipe qui utilisait le plugin Checkstyle . Plutôt que d'utiliser les fonctionnalités prêtes à l'emploi, 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 nous avons martelé les choses. Nous avons tous appris quelque chose au cours du processus et renforcé ces muscles de développement.
(Exemples de nos décisions: 72 caractères de large est trop petit, mais 120 était mieux; il vaut mieux utiliser _ALLCAPS pour les finales statiques; appliquer une sortie unique d'une fonction est une bonne idée.)
Lorsque nous avons passé en revue le code, l'une des premières questions était: "L'avez-vous exécuté via Checkstyle?" Le respect des normes de codage a été largement automatisé, et cela a détourné l'attention du critique qui était pointilleux. Il était merveilleusement facile de demander à Checkstyle de mettre en évidence une signature de méthode, de cliquer avec le bouton droit et de changer une variable en finale. Il pourrait également corriger les indentations et les accolades afin que le code de tout le monde ait une apparence similaire. Manquer un Javadoc pour une fonction publique? Checkstyle marquera la fonction.
(La suppression de l'odeur de code est plus importante que la mise en forme cohérente. C'est un avantage des outils automatisés.)
Je placerais des outils automatisés comme Checkstyle moins comme imposant le même format et plus sur encourageant une apparence et une sensation similaires. Et lorsque vous élève des chats, un outil automatisé peut aider à affiner les compétences et à réduire l'odeur du code sans écraser les egos fragiles.
Si vous allez vous en tenir à la même IDE et incorporer des outils de formatage, c'est une bonne idée car vous n'exigez pas trop d'efforts. Gardez les règles simples en mettant l'accent sur la lisibilité et pas rétention anale . Cela devrait être le bâton de mesure.
Bien qu'une boule de boue de forme cohérente soit meilleure qu'une simple boule de boue, il vaut mieux passer votre temps à la nettoyer au lieu de devenir trop pointilleux sur la destination des supports. Ne vous transformez pas en gestionnaire épinglé qui a l'impression de faire son travail en comptant les espaces en retrait lors d'une révision de code et en s'assurant que les nouvelles pages de couverture sont sur 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-behind-the-different-brace-forms
Si c'est le cas, surmontez-le et faites quelque chose.
Je recommande fortement que les humains appliquent le formatage du code et que les infractions mineures soient gracieusement négligées ou retouchées. Les raisons de ceci sont, brièvement,
- La machine se trompe au pire moment possible, et généralement lorsque vous utilisez une nouvelle fonction de langue. Comment gérera-t-il les fermetures en Java, etc.? Jalopy a des problèmes avec les énumérations avec les fonctions membres.
- Je pense que c'est un fardeau très raisonnable de charger le programmeur de produire du code pour l'entreprise qui ressemble à du code d'entreprise. J'ai trouvé utile de mentionner que c'est ainsi que le code est formaté "ici", pas comment tout le code devrait être formaté partout. Leur ancienne entreprise a peut-être choisi une voie différente, et c'est OK. À la différence du langage vernaculaire, il existe des idiomes spécifiques à votre culture de code que vous souhaitez faire ressortir.
- L'application de la syntaxe du code est mieux effectuée avec les revues de code:
- Si la mise en forme est importante, elle incite votre organisation à effectuer des révisions de code. C'est extrêmement avantageux.
- Si une règle de formatage est violée, un être humain peut la regarder et juger mieux qu'une machine si l'intention est exprimée de façon plus nette. Ceci est très rare, mais arrive parfois.
En ce qui concerne la "lisibilité => productivité", la structure du code (comme les classes et fonctions à responsabilité unique) vous achètera beaucoup plus rapidement que le formatage du code. Le formatage du code peut être utile, mais différents esprits analysent les déclarations différemment - tout le monde ne sera pas "plus productif". Je voudrais doubler la structure du code par rapport au formatage, car cela vous incitera également à effectuer des révisions de code et à faire réfléchir l'équipe sur le fonctionnement du programme, et non sur 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 de la façon dont le code doit ê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 DDD, mais c'est un excellent exemple car il est si bien défini.
Je suppose que le thème de cette réponse est Faire des revues de code et laisser le formatage s'écouler de la culture et sortir du processus de revue.
Généralement, en supposant que vous embauchez des développeurs raisonnables, c'est une mauvaise idée d'imposer un format de code universel. C'est cependant une bonne idée d'adopter le code directives.
Je n'ai jamais vu un ensemble de règles de formatage de code qui optimise la lisibilité dans tous les cas. De même, il n'y a pas de règles de grammaire applicables à 100% en anglais: nos cerveaux ne sont tout simplement pas câblés de cette façon. Utilisez donc des directives, mais donnez aux développeurs la liberté de les remplacer comme bon leur semble.
Cela étant dit, une règle plus difficile de "suivre la convention de code qui existe déjà dans le fichier/projet" est une bonne règle.
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!
Mon principal argument contre le style de codage commun est qu'un programmeur expérimenté est utilisé pour lire son propre style. Vous pouvez entraîner la main à écrire un style spécifique, mais il est presque impossible de former l'œil à 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é forcé de l'écrire dans un mauvais style, il sera très mécontent et moins productif. C'est de mon expérience.
Je ne suis pas trop familier avec Eclipse mais le formatage automatique lors de la sauvegarde sonne comme une idée horrible. Un développeur doit avoir un contrôle total sur son code, que le style de codage soit imposé ou non. L'opération de sauvegarde ne doit pas modifier 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 est une connerie dans le meilleur des cas et tout simplement stupide dans le pire des cas. Les grands programmeurs produiront toujours un code élégant quel que soit le style.
Je suis également fortement pro en donnant à chaque développeur la propriété d'unités de code spécifiques et contre 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 merdique sachant que des bogues reviendront le chasser.
Enfin, toute personne ayant un style de codage professionnel suppose toujours que son propre style de codage sera sélectionné et que tout le monde suivra. Imaginez que le style de codage que vous aimez le moins parmi tous vos co-développeurs soit sélectionné en standard. Êtes-vous toujours en faveur d'imposer un style de codage?
Un format pour les gouverner tous ... est-il vraiment optimal?
C'est comme conduire la voiture de quelqu'un d'autre ...
Bien sûr, vous pouvez monter et conduire n'importe quelle voiture, mais vous serez plus en sécurité, plus confortable et moins susceptible de tomber en panne si vous prenez le temps d'ajuster le siège, le volant et les rétroviseurs à VOTRE préférence.
Avec le code, la mise en forme affecte votre confort dans la lecture et la compréhension du code. S'il est trop éloigné de ce à quoi vous êtes habitué, il faudra 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 de code. Combien de fois avez-vous eu un formateur de code détruire un bloc de commentaires qui était bien aligné sous forme de tableau? Combien de fois avez-vous délibérément aligné une expression complexe d'une certaine manière pour augmenter la lisibilité, seulement pour que la mise en forme automatique la transforme en quelque chose qui "respecte les règles", mais est loin moins lisible?
Parfois, il existe des solutions de contournement à ces problèmes, mais les développeurs ont des choses plus importantes à régler que la façon d'empêcher le formateur automatique de modifier le code.
Avoir des règles de formatage, mais laisser une certaine liberté pour appliquer le bon sens.
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 le style et les conventions de dénomination sont importants dans une certaine mesure, il est également assez facile de perdre trop de temps à y penser. Il vaut mieux répondre par l'exemple.
Sur un projet particulier sur lequel j'étais, il n'y avait aucune convention du tout. 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 troublant. Le style était moins problématique que le problème des conventions de dénomination. Un développeur ferait référence à des éléments d'interface utilisateur avec une horrible notation hongroise (une pratique stupide à l'ère des IDE modernes), un nommerait des membres privés d'une manière, un autre les nommerait différemment. Vous n'avez jamais su ce que vous regardiez.
À l'extrême opposé, une équipe a utilisé StyleCop (c'était un projet .Net) dans le cadre de son processus de construction. Le pire, c'est qu'ils ont également utilisé la plupart des règles par défaut. Donc, vous feriez quelque chose de totalement normal en termes d'espacement des lignes ou de placement des accolades, et la construction vomirait à cause de cela. Tant de temps a été gaspillé simplement en ajoutant des espaces et des lignes aux trucs, et tout le monde, y compris les mecs qui ont insisté pour utiliser StyleCop, ont fini par le faire presque à chaque validation. C'était une énorme perte de temps et d'argent.
Donc, ce que je veux dire ici, c'est qu'être inflexible n'est pas la réponse, mais être dans le Far West ne l'est pas non plus. La vraie réponse est de trouver l'endroit qui a le plus de sens, ce qui, à mon avis, est de ne pas avoir d'outils automatisés pour vérifier les choses, mais ne pas non plus jeter les conventions au vent.
Les bons développeurs sont des gens créatifs, donnez-leur une licence artistique. "Restez simple" devrait être le mantra des programmeurs. J'ai deux règles:
Règle 1: Donnez des variables/curseurs/objets/procédures/quels que soient les NOMS SENSIBLES. Des noms sans ambiguïté qui donnent du sens et de la 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 aide notre suivi des changements et nos révisions de code. git (et la plupart des autres outils de contrôle de source) peuvent 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 des programmeurs.