Je déteste l'une de nos normes de codage et cela me rend fou, comment la traiter? [fermé]

Avertissement : Pas aussi exagéré que le titre le suggère, mais cela me met toujours mal à l'aise. Je vais juste exprimer honnêtement, alors prenez-le avec un grain de sel. Imaginez simplement que je parle de cette norme de codage avec laquelle vous n'aimez pas travailler.

Edit : Le fait que je ne l'aime pas, ne signifie pas que je ne l'utilise pas ou ne l'applique pas.

J'ai décidé de poser cette question dans l'esprit de comment surmonter une norme que vous n'aimez pas, de ne pas obtenir d'aide sur la meilleure façon de discuter de la façon dont elle peut être modifiée (bien que tout commentaire concernant cette dernière partie soit apprécié). De plus, je travaille dans une grande entreprise et un tel changement de quelque chose qui a vécu si longtemps et qui importe si peu est peu probable.

La norme est la norme d'ouverture-accolade-accolade-sur-ligne dédiée:

somefunction()
{
    //...
}

Au lieu du * clairement supérieur * (notez le ton plaisantant / frustré):

somefunction() {
    //...
}

Mes arguments personnels contre la norme:

• Il gonfle le code : lignes supplémentaires inutiles
• Plus difficile à taper : bien que ce soit probablement moi qui ai du mal avec la norme, je sais qu'une frappe supplémentaire n'est pas si mauvaise.
• Pas plus facile à lire : je commence à lire une déclaration de fonction, une instruction if ou toute autre instruction d'empilement de portée et je n'ai déjà pas besoin de chercher une accolade ouvrante. Les blocs imbriqués avec cette norme me mettent en colère pour une raison quelconque.
• Utilisé par des personnes issues d'un environnement Microsoft IDE : je pense qu'il devrait y avoir une raison argumentée (ou plus) derrière une norme, et pas seulement la prendre par paradigme.

Leurs arguments (et ma façon de leur répliquer en interne):

• Plus facile à lire car vous pouvez voir immédiatement où les blocs commencent et se terminent immédiatement : je ne peux pas comprendre cela, à quoi sert le bloc si vous ne savez pas de quoi il appartient, alors vous devez lire à l'envers.
• Je l'ai utilisé dans un IDE Microsoft et je l'ai aimé : Euh ... ok?
• C'est dans la norme : * grincements de dents *

Suis-je le seul à avoir une position d'opinion contre une norme spécifique?, Comment avez-vous réussi à les surmonter?, Quelle est votre opinion sur ce que devrait être cette norme (juste pour le plaisir)?

Si vous voulez surmonter cela - il y avait une citation de Torvalds:

Les mauvais programmeurs s'inquiètent du code. Les bons programmeurs se soucient des structures de données et de leurs relations.

Considérez maintenant, où cela place-t-il les programmeurs qui s'inquiètent d'une chose aussi mineure que le style de contreventement imposé par leur norme de code? Votre base de code est-elle par ailleurs si vierge que le contreventement est le seul problème qui mérite le temps de discuter?

Certaines personnes aiment ça à votre façon et d'autres pas. De toute façon, quelqu'un va être ennuyé. C'est votre tour cette fois. Aspirez et continuez votre travail.

La norme de l'équipe est-elle documentée? Si c'est le cas, y a-t-il des raisons dans le guide de style? Honnêtement, j'ai dû le sucer une tonne de fois et faire un vrai travail. Il y a de pires problèmes à avoir, mais je te sens - c'est toujours un problème (je suis d'accord avec toi sur le style, au fait).

Ce qui m'a aidé à m'en sortir:

1. Réalisé qu'il y a de réels avantages à un seul style (quel qu'il soit). Ou au moins un tas de gens le pensent .
2. Exactement ce que vous venez de faire, écrivez pourquoi cela ne va pas, afin que vous puissiez bien argumenter à l'avenir.
3. Utilisez un outil de coiffage pour l'amour de Dieu , il sauvera votre santé mentale. ReSharper , CodeMaid , StyleCop , JSLint , CheckStyle , etc ... même Visual Studio va le faire pour vous .
4. Donnez un coup de pied à ce projet et soyez prêt pour le prochain lorsque vous pourrez définir les normes.

La supériorité d'une convention sur l'autre est * clairement arbitraire * .

Les problèmes de lisibilité auxquels vous êtes confrontés, ou vos coéquipiers seraient confrontés à votre norme, ne sont qu'une résistance psychologique au changement.

L'argument de la lisibilité objective est en faveur de la * cohérence * sur l'ensemble de la base de code.

Pensez à une époque où vous étiez sûr que vous aviez raison sur quelque chose et au cours d'une période de temps, vous avez réalisé que vous aviez tort, ou du moins que vous aviez réagi de manière excessive il y a toutes ces années. Considérez la possibilité que vous vous trompiez à nouveau, et donnez le temps à la nouvelle norme de codage ou au processus de vous convaincre.

Mes propres normes font rage quand j'étais relativement nouveau dans le codage (disons cinq ans dans ma carrière) était de savoir si les identifiants multi-mots devraient être WrittenLikeThisou written_like_this. Je ne dirai même pas lequel j'ai préféré, mais le fait est qu'après un certain temps j'ai changé de camp et après un certain temps, je m'en fichais de toute façon.

La différence standard que vous décrivez avec les accolades est largement arbitraire. Les deux façons sont également bonnes et pour une entreprise, tant que tout le monde le fait de la même manière, tout va bien.

Le "clairement supérieur" dont vous parlez est le genre de supérieur dont les gens parlent quand ils parlent de choses "auxquelles ils sont habitués".

Vous vous y habituerez assez tôt et dans un an environ, l'autre voie sera "clairement supérieure".

Donc, en bref: faites-y face.

Ce sujet particulier équivaut à une guerre de religion entre ceux qui préfèrent un style à l'autre. Très peu de gens sont ambivalents ...

En fin de compte, ni l'un ni l'autre n'a raison ni aucun tort.

Les guides de style et les normes de codage existent pour un certain nombre de raisons - et un aspect clé est d'assurer l'uniformité de la mise en page, ce qui vise à réduire le nombre d'erreurs évidentes et à améliorer la maintenabilité.

Suis-je le seul à avoir une position d'opinion contre une norme spécifique?

La réponse courte est "Non", vous n'êtes pas le seul. Mais il y a des choses plus importantes à se soucier. Même dans les normes auxquelles on peut contribuer, il y aura toujours un compromis - soyez témoin de certains des aspects qui ont fait partie des C99 et C12 qui n'ont aucun sens pour moi.

Même MISRA-C (sur lequel j'ai une influence directe) contient des éléments avec lesquels je ne suis pas personnellement d'accord - mais je peux comprendre pourquoi les autres ressentent la justification.

comment vous en êtes-vous sortis?

Et c'est là que réside la réponse - plutôt que de vous concentrer sur pourquoi vous ne l'aimez pas personnellement, essayez de comprendre pourquoi la personne / les personnes qui l'ont accepté l'ont fait.

Des règles sont généralement introduites (dans une porte stable qui se ferme après que le cheval s'est verrouillé) pour résoudre un problème précédent. Et si la règle est toujours absurde, parlez au propriétaire standard et essayez de les "éduquer".

Je pense que vous avez juste besoin de continuer. Je vais essayer d'adresser vos notes avec mes propres opinions:

• Code de ballonnements

  Une ligne de code supplémentaire n'est pas du tout un ballonnement, sauf si vous écrivez des centaines de méthodes dans une seule classe, ce qui ajoutera des centaines de lignes supplémentaires. Là encore, si vous avez des centaines de méthodes dans une seule classe, vous avez un autre problème.

• Plus difficile à taper

  Je ne peux plus être en désaccord avec vous à ce sujet, vous devez quand même appuyer sur la touche retour pour accéder à la ligne suivante. Qu'en est-il plus difficile à taper?

• Plus difficile à lire

  Je pense que chaque ligne d'un morceau de code devrait avoir une fonction spécifique. Après cela, vous devrez définir le nom de la méthode sur une ligne, puis les accolades d'ouverture et de fermeture sur leurs propres lignes distinctes.

• Utilisé par des personnes issues du milieu MS IDE

  Euh ..... ok?

En résumé, il semble que vous soyez tatillonne à propos d'être un développeur .Net par opposition à tout autre type de développeur comme s'il était inférieur car ils utilisaient un IDE par défaut à cette norme.

Suis-je le seul à avoir une position d'opinion contre une norme spécifique?

Bien sûr que non. Les réunions pour déterminer les normes de codage sont horribles! Ils traînent pendant des heures et les participants s'investissent personnellement pour obtenir leurs propres idiosyncrasies préférées (et invariablement erronées, sauf la mienne) inscrites dans la norme. À la fin, personne n'est satisfait du résultat. Si quelque chose peut être pire que la réunion des normes de codage, ce sont les réunions formelles d'examen du code dans les plusieurs mois qui suivent la détermination de la norme: certaines personnes essaient d'adopter la norme, tandis que d'autres (intentionnellement ou non) l'ignorent, et vous obtenez heures de rétroaction comme: Sur les lignes 132, 142, 145, 181, 195 et 221 de SillyFileConverter.cpp vous mettez l'accolade d'ouverture sur la même ligne lorsque la norme de codage dit clairement qu'elle devrait être sur la ligne suivante !

comment vous en êtes-vous sortis?

À leur manière, les rencontres aident. Même si vous sympathisez entièrement avec le gars qui a laissé l'accolade d'ouverture sur la même ligne que le conditionnel, ou quoi que ce soit, vous serez quand même agacé par lui pour avoir perdu votre temps en ne pas simplement le sucer et en suivant le standard stupide. Si le gars est un curmudgeon et fait la même chose encore et encore, cela devient encore plus ennuyeux. Être ennuyé par ce comportement facilite la justification de l'écriture dans un style un peu différent de ce que vous préférez - vous ne voulez certainement pas être ce type , après tout.

Même si vous n'êtes pas soumis à des révisions de code formelles interminables, vous pouvez essayer de revoir votre propre code spécifiquement pour la conformité à la norme. Peu importe ce que vous pensez de la norme, vous comparez simplement ce que vous avez écrit à ce que dit la norme. Si vous vous trompez chaque fois que vous ne vous conformez pas, cela peut fournir certains des commentaires négatifs dont vous avez besoin pour vous aider à adopter la norme.

Avec ce genre de chose, je me souviens de Gulliver à Lilliput. Les Lilliputiens avaient mené une guerre au cours de laquelle ouvrir un œuf à la coque. (Le grand endian original, petit combat endian).

Profitez-en pour rire de vous-même, ils ne viennent pas assez souvent en affaires.

Votre exemple particulier est regrettable car c'est un exemple avec lequel certains seront d'accord et d'autres pas. Je suis en désaccord avec vos arguments contre, par exemple, et je suis sûr que beaucoup d'autres le seront aussi, tout comme je suis sûr que beaucoup d'autres seront d'accord avec eux. Cela me fait presque penser que la question devrait être close car elle est tellement subjective.

Cependant, la question sur la façon de traiter une norme avec laquelle vous n'êtes pas d'accord peut être mieux résolue. Je pense que la réponse est que lorsque des lignes directrices de style existent et sont convenues et ont été utilisées, la réponse est simplement de sourire, de la supporter et de la gérer. Considérez que la cohérence est plus importante. Si la directive est inexacte ou erronée, il peut y avoir un argument en faveur du changement, mais c'est stylistique, il n'y a donc aucun argument en dehors des préférences personnelles.

Je suis originaire de Java à l'origine, j'ai donc suivi la norme que vous avez mentionnée. Je suis ensuite passé à plus de C ++ et C # où le style que vous détestez est utilisé. Mais il n'a pas de bonne ou de mauvaise réponse. Ce qui est plus important, c'est d'avoir une norme suivie par tout le monde. Si une norme de codage est stylistique comme celle-ci et n'est pas clairement erronée, essayer de faire valoir qu'elle ne fera que provoquer des frictions dans l'équipe.

Un formateur + crochet d'enregistrement est un bon début. Mais ce n'est pas suffisant, car ce que vous écrivez n'est pas aussi important que ce que vous regardez toute la journée. Dans certaines situations, l'approche du mode Lunettes d' Emacs - conserver les fichiers dans leur style mais les afficher plus près de votre style - est attrayante.

Mon expérience avec - face exactement au problème pour lequel il a été écrit, CamelCapsvs underscore_separated- a été qu'il est rapidement devenu plus ennuyeux qu'utile, mais pendant quelques semaines, cela a facilité ma transition vers l'acceptation (à contrecœur) du style de l'entreprise, et a fourni un débouché pour canaliser ma colère ("ah je déteste ça, laisse moi ajuster les réglages encore ... là, au moins j'ai fait quelque chose ") ;-)

Quoi qu'il en soit, le mode Lunettes ne gère pas le placement de l'accolade, vous n'utilisez probablement pas Emacs et ne lisez pas le code exclusivement dans votre éditeur :-(
Mais le dernier point est également une opportunité - si vous lisez code la plupart du temps dans un outil distinct, vous pouvez le pirater pour convertir des styles sans vous soucier du bruit de reformatage aller-retour - car il est en lecture seule! Plus précisément, si vous lisez du code dans certaines interfaces Web, utilisez Greasemonkey.

Voici quelques idées plus faciles pour une atténuation modérée:

• Choisissez une police plus large mais pas si haute pour récupérer les lignes d'écran perdues.

  • Utilisez le plein écran plus souvent, si disponible.

• Configurez les accolades à mettre en surbrillance dans une couleur subtile (et une police plus petite?), Ce qui les rend moins visibles que le reste du code. L'indentation devrait être suffisante pour la lecture, en particulier. avec l'espace vide des {lignes ...

• Assurez-vous que votre éditeur met en évidence l'accolade d'ouverture correspondante lorsque vous avez terminé }- peut aider un peu lorsque vos yeux vont instinctivement au mauvais endroit.

• Re "plus difficile à taper": obtenez un véritable éditeur, configurez-le pour ouvrir automatiquement une nouvelle ligne lorsque vous appuyez sur {.

Vivre avec.

Il s'agit clairement de cosmétiques et cela ne change rien à la qualité du code ou à votre productivité en tant que développeur. Rien ne vaut recommencer un argument.

Pour ce type de norme de codage, je choisirais la cohérence à travers la base de code et la lisibilité par rapport à toute approche "religieuse" particulière (même raisonnée).

Le considérer comme une décision démocratique de la majorité des membres de l'équipe au sujet d'un problème moins important peut vous aider à le surmonter.

C'est la norme:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

La plupart de ceux qui disent "c'est la norme" suivent le principe des "cinq singes".

Allez-y et utilisez le style que vous voulez. Ensuite, utilisez un embellisseur de code pour changer le code au format standard, ou redressez votre propre petite application qui convertira le code de votre style au style standard donné. Utilisez l'embellisseur avant de vérifier le code.
Vous pouvez également faire l'inverse pour changer le code archivé du format standard à votre format, lorsque vous travaillez dessus.