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.
la source
Réponses:
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.
la source
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 ...
la source
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.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
merging
code du système 'Contrôle de version'.la source
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?
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.
la source
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:
la source
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.
la source
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.
la source
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,
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.
la source
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!
la source
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.
la source
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?
la source
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.
la source
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.
la source
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.
la source
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" .
la source
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.
la source
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
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.
la source