Traiter avec des collègues qui n'ont pas un style de codage cohérent?

Que faites-vous lorsque vous travaillez avec quelqu'un qui a tendance à écrire du code stylistiquement incorrect? Le code dont je parle est généralement techniquement correct, raisonnablement structuré et peut même être algorithmiquement élégant, mais il a l' air moche . Nous avons:

• Mélange de différentes conventions de dénomination et titres ( underscore_styleet camelCaseet UpperCamelet CAPStous appliqués plus ou moins au hasard à différentes variables dans la même fonction)
• Espacement bizarre et incohérent, par exemple Functioncall (arg1 ,arg2,arg3 );
• Beaucoup de mots mal orthographiés dans les commentaires et les noms de variables

Nous avons un bon système de révision de code où je travaille, donc nous pouvons regarder et réparer les pires choses. Cependant, il semble vraiment mesquin d'envoyer une révision de code qui se compose de 50 lignes de "Ajouter un espace ici. Épelez 'itarateur' correctement. Modifiez cette capitalisation. Etc."

Comment pourriez-vous encourager cette personne à être plus prudente et cohérente avec ce genre de détails?

Convenir d'une convention de codage

Même s'il s'agit d'un téléavertisseur. Je suggère à toute l'équipe de s'asseoir et de s'accorder sur une convention de codage de travail de base que toute l'équipe peut utiliser.

Je pense que vous devez juste continuer à faire ce que vous faites. Avoir un ensemble clair de directives de codage et les appliquer lors des révisions de code. Si un développeur obtient 50 ou 100 lignes "Ajouter un espace ici" et "Épeler" l'itérateur "correctement" à chaque fois qu'il essaie de vérifier quelque chose, et qu'il n'est en fait pas autorisé à s'enregistrer avant que tout cela ne soit corrigé, finalement il Je vais devoir commencer à écrire du code plus propre juste pour éviter les tracas.

Je pense que si vous réparez ces choses vous-même, comme l'a suggéré NimChimpsky, vous nettoierez cette personne pour toujours.

J'appelle BS sur tous ceux qui ont dit que les erreurs d'orthographe et de mise en forme des noms de variables n'avaient pas d'importance. De toute évidence, ils n'ont lu que leur propre code. Et remarquez ce mot juste là - lisez. Imaginez que vous lisiez un livre avec beaucoup d'erreurs d'orthographe, un formatage en purée, un espacement de ligne incohérent et divers autres paresseux répandus dans beaucoup de code source. Ce serait fastidieux.

Pour une profession où votre syntaxe doit être correcte à 100% pour fonctionner, il n'y a tout simplement aucune excuse pour un vrai développeur de ne pas avoir un style de code propre et cohérent. Tout le reste est négligence et paresse. Je remets toujours en question l'exactitude du code au format bâclé dans l'implémentation.

Nous avons un bon système de révision de code où je travaille, donc nous pouvons regarder et réparer les pires choses. Cependant, il semble vraiment mesquin d'envoyer une révision de code qui se compose de 50 lignes de "Ajouter un espace ici. Épelez 'itarateur' correctement. Modifiez cette capitalisation. Etc."

Je le changerais moi-même et ajouterais ensuite un commentaire poli dans le code.

cela suppose qu'il existe déjà un guide de style comme la question l'indique:

Nous avons un bon système de révision de code

Donc, ma suggestion est un dernier recours, je pense que c'est tout aussi rapide de la changer vous-même et de laisser un commentaire, que d'envoyer un e-mail ou autre chose.

Je pense que les conventions telles que la dénomination des classes et des variables sont importantes et doivent être suivies, un code élégant et efficace aussi, mais au risque de voir ma réponse rejetée plusieurs fois, je dois dire qu'en général le paradigme du "joli code" qui est beaucoup poussé est à mon humble avis très surfaite.

Tout d'abord, le développeur qui l'a écrit devra le maintenir en premier lieu, et s'il est jamais heurté par un bus et qu'un autre programmeur ne peut pas comprendre comment cela fonctionne parce que le code n'est pas "joli", je dirais que l'autre développeur n'est pas très bon de toute façon. Et il y a beaucoup de formateurs / embellisseurs automatisés, donc tout le monde peut les utiliser pour embellir le code si nécessaire, sans perdre de temps tout en étant "dans le flux" / "dans la zone".

Veuillez noter que je ne préconise pas le codage de style spaghetti / cowboy ici, en fait, j'ai vu du code spaghetti très bien formaté (corps de fonction couvrant 4 à 5 écrans, variables globales dispersées autour de différents fichiers de code source, généralement mauvais choix de noms , etc).

Un de mes collègues écrit du HTML de manière à ce que ma peau rampe. Imaginez mon html agréable et structuré avec deux retraits spatiaux, découpés en morceaux par des balises ajoutées à la fin de la mienne qui se terminent sur la même ligne ou sur la suivante comme un ivrogne qui a besoin de jeter son bras autour de vous pour rester debout. Les nouvelles lignes sont rarement en retrait, mais si elles le sont, je suis sûr qu'il y a un trou noir très chaotique dans une partie de la galaxie crachant des valeurs de température irrationnelles de telle sorte que ses chiffres reflètent en quelque sorte le nombre d'espaces ou d'onglets utilisés dans une telle indentation par cette femme. Si j'ai de la chance, je verrai une balise d'entrée fermée par " </input>". Cauchemar total que vous pouvez comprendre.

Personne ne semble comprendre cela non plus, voir comment pour la plupart des hauts placés ici, le code organisé ou le code non organisé est comme la différence entre nous qui mettons du fromage suisse ou du fromage américain sur nos sandwichs, c'est-à-dire qu'ils s'en foutent vraiment. J'ai commencé à le laisser glisser parce que j'étais stressé par un autre projet, et je pense qu'elle a commencé à réaliser à quel point c'était difficile de comprendre un code comme ça avant de vouloir s'améliorer. Mon conseil serait de démontrer pourquoi il est préférable de styliser votre code plus que de simplement leur dire de le faire.

Le code dont je parle est généralement techniquement correct, raisonnablement structuré et peut même être algorithmiquement élégant ...

Soyez heureux que vous ayez tout cela. La plupart des programmeurs vous donneront peut-être la première chose sur cette liste. Je pense que le nommage et l'espacement variables sont la chose la moins importante à s'inquiéter.

On dirait que vous devez configurer et accepter une convention de style. Si vous ne l'avez pas, vous aurez des bibliothèques qui ont 3 retraits d'espace, d'autres qui en ont 4, certaines qui utilisent Camel Case et d'autres qui utilisent underscore_case.

Les modifications que vous souhaitez faire vos préférences personnelles ou avez-vous une norme réelle à suivre? Si vous n'avez pas de norme réelle, ne le faites pas. Fixez d'abord une norme. Ensuite, vous pouvez obtenir un logiciel qui peut être configuré pour refactoriser le code aux paramètres standard (enfin au moins certaines choses).

Si vous avez une norme, commencez à l'appliquer dans la révision du code. Il n'y a aucun intérêt à avoir une norme si vous ne l'appliquez pas lors de la révision du code. Cela signifiera beaucoup de travail supplémentaire en maintenance, car les gens devront corriger l'ancien code qui ne respectait pas la norme à l'origine lorsqu'ils le touchent.

Même sans standard, insistez pour corriger les fautes d'orthographe dans les noms de variables (je ne m'inquiéterais pas particulièrement des commentaires) car ils rendront tous ceux qui touchent le code fou à jamais.

Les normes de codage doivent être identifiées pour que tout le monde sache ce qu'elles sont et ensuite elles doivent être appliquées. Il devrait y avoir des conséquences à ne pas suivre les règles.

Voici les éléments qui devraient vous inciter:

1. Les révisions de code seront fastidieuses et plus longues que nécessaire.
2. Le code sera rejeté plus souvent.
3. Les horaires ne seront pas respectés.

Si cette personne n'a pas à s'inquiéter de cela parce que personne n'applique vos règles ou qu'elle ne se soucie pas si elles sont improductives (et personne ne fait rien à ce sujet), vous ne pouvez pas faire grand-chose à ce sujet.

Je serais tenté de suggérer d'avoir un chat privé et de voir si vous pouviez tous les deux trouver une cause profonde:

1. Le collègue est-il pressé et parce que quelqu'un voulait le code hier, la personne essaie de faire fonctionner quelque chose le plus rapidement possible? Cela peut être l'occasion d'informer cette personne de se concentrer davantage sur la qualité que la vitesse dans son travail. Un mantra comme «Prenez votre temps» pourrait être utile si ce n'est pas contre-productif.

2. Comment la personne perçoit-elle son travail? S'il y a un sentiment de fierté, alors vous pouvez avoir un angle à utiliser pour l'améliorer. Si c'est juste un travail qui paie les factures, il peut être beaucoup plus difficile d'obtenir des changements. Savent-ils qu'ils ne font pas du bon travail, mais qu'ils en sont si proches?

3. Cette personne est-elle en désaccord avec les conventions et essaie de coder pour protester? Si oui, alors vous pourriez avoir un gros problème, mais cela vaut la peine de savoir si c'est le cas ou si la personne est simplement paresseuse? Quels types de motivation peuvent être utiles ici, par exemple pourriez-vous faire appel à la cupidité, à la fierté ou à tout autre vice pour amener la personne à s'améliorer. C'est sournois, mais peut-être efficace si essayer la route du bon gars n'en mène nulle part.

4. Comment gagner des amis et influencer les gens ont quelques suggestions en termes de persuasion qui peuvent fonctionner, telles que louer des améliorations et donner à la personne une bonne réputation à défendre.

Quant à savoir pourquoi cela doit être fait en privé, voici quelques raisons:

1. Il y a de bonnes chances d'humiliation, de critique ou d'autres désagréments qui sont mieux gardés derrière une porte que laissés à l'air libre où quelqu'un peut sentir que son personnage est assassiné.

2. Vous voulez encourager cette autre personne à s'ouvrir un peu. Un défi ici est que certaines personnes sont tellement gardées que cela peut prendre beaucoup de temps pour les faire abattre leurs murs.

3. Si possible, je suggère d'essayer de le faire un peu loin du bureau. Sortez pour le déjeuner, faites une promenade ou faites quelque chose pour que l'environnement soit suffisamment modifié pour que la personne se sente un peu plus à l'aise. Cela peut être un défi et nécessite de connaître la personne, mais l'idée ici est qu'au bureau, certaines personnes porteront un masque de travail qui ne sera probablement pas utile ici.

4. Soyez prêt pour que la conversation devienne plutôt houleuse ou laide, mais cela pourrait bien être un bon signe si vous pouvez garder l'autre personne engagée et avoir un bon dialogue. Certaines personnes aiment garder les choses à l'air libre et d'autres peuvent préférer des façons plus subtiles de faire avancer les choses. La clé est de vous assurer que vous écoutez suffisamment l'autre personne pour faire preuve d'empathie et essayer de comprendre son côté.

Nous avons un test JUnit qui recherche les problèmes de formatage. Il s'exécute dans le cadre de la génération. J'obtiens continuellement peu en omettant un espace entre if, while ou for et la parenthèse ouvrante. Cependant, notre code est toujours formaté.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

L'embellissement de code comme unscrutify sera en mesure de résoudre certains de vos problèmes. Si vous êtes prêt à payer pour cela, il existe des logiciels de haut niveau qui intègrent les règles dans le code source lui-même comme Parasoft . Parasoft oblige à écrire le code dans un style uniforme. Vous pouvez également intégrer vos propres règles. Lorsque de tels outils sont utilisés, les développeurs sont obligés d'utiliser un style uniforme. Et après un certain temps, ils s'y habitueront.

Si vous utilisez Eclipse, activez Enregistrer les actions pour les éditeurs Java et dites à tout le monde de l'utiliser. Cela résout les problèmes de formatage à chaque sauvegarde, mais ne corrige pas une mauvaise capitalisation. Cela pourrait être très utile!

Est-il difficile de suivre les conventions de style? Je comprends les fautes d'orthographe mais le reste est un indicateur de la pensée bâclée et du codage. Dites à la personne qu'elle doit être plus cohérente en ce qui concerne le code de production, car elle n'est pas la seule à l'examiner. Il est tout simplement grossier, égoïste et inconsidéré d'écrire du code de production dans un style incohérent.

LOL. Vous détesteriez absolument mon code. Je ne peux pas épeler pour me sauver la vie et je m'en fiche.

Mais je sais que certaines personnes se soucient vraiment de ces choses.

Je vous suggère de licencier la personne qui écrit ce code laid si elle ne change pas, puis de trouver quelqu'un qui rend les choses vraiment jolies et espérons pouvoir écrire du code qui

est généralement techniquement correct, raisonnablement structuré et peut même être élégant d'un point de vue algorithmique

et s'ils ne le peuvent pas, vous pouvez au moins montrer le joli code cassé au client et le vendre!

Mais sérieusement. Concentrez-vous d'abord sur les choses réellement importantes. Si vous ne pouvez pas trouver une bonne raison solide à l'extérieur "ça fait mal à mes sensibilités délicates" alors ignorez-le pour l'instant. Si c'est vraiment important, asseyez-vous avec la personne et convaincez-la de cette importance. Des choses comme les normes qui permettent de faire facilement la différence entre le niveau de classe, le niveau de méthode, les variables partagées et constantes font une différence. Si le codeur en question se soucie du tout de sa profession, il comprendra et essaiera de faire la bonne chose.

Ma solution lorsque je traitais avec des ressources externalisées qui ne donnaient pas de &% $ # sur le formatage (ou des bogues facilement évitables d'ailleurs) était d'avoir le serveur de build pour appliquer cela. J'ai créé un travail de serveur CI qui s'exécutait chaque nuit pour extraire le code, exécuter Jalopy et findbugs, puis archiver le code. Une fois que l'autre équipe a appris que ne pas utiliser les conventions de code standard rendrait leur travail plus difficile, ils ont commencé à utiliser leur IDE pour maintenir un format standard.