Dois-je suivre un mauvais style de codage juste pour suivre les conventions établies sur mon lieu de travail?
Je travaille à mon travail depuis environ un an. Je travaille principalement dans notre interface graphique qui utilise des méthodes à partir d'un backend C, mais je n'ai généralement pas à les traiter, sauf pour les valeurs de retour. Notre interface graphique est structurée assez raisonnablement, compte tenu de nos limites.
J'ai été chargé d'ajouter une fonction à la partie ligne de commande du programme. La plupart de ces fonctions font environ 300 lignes et sont difficiles à utiliser. J'essaie d'en rassembler des morceaux pour obtenir des informations d'alarme spécifiques et j'ai du mal à rester organisé. Je sais que je complique mes tests en le faisant dans une seule fonction longue.
Dois-je simplement tout garder dans une fonction énorme selon le style des fonctions existantes, ou dois-je encapsuler les alarmes dans leurs propres fonctions?
Je ne sais pas s'il est approprié d'aller à l'encontre des conventions de codage actuelles ou si je devrais simplement mordre la balle et rendre le code un peu plus déroutant pour moi.
En résumé, je compare
showAlarms(){
// tons of code
}
contre
showAlarms(){
alarm1();
alarm2();
return;
}
alarm1(){
...
printf(...);
return;
}
EDIT: Merci pour les conseils de tout le monde, j'ai décidé de concevoir mon code factorisé, puis de demander ce qu'ils veulent, et s'ils le veulent tout en un, je peux simplement couper de mon code factorisé et le reconvertir en 1 grande fonction. Cela devrait me permettre de l'écrire et de le tester plus facilement même s'ils veulent tout le code dans une seule définition.
MISE À JOUR: Ils ont fini par être satisfaits du code factorisé et plus d'une personne m'a remercié d'avoir créé ce précédent.
C'est vraiment entre vous et vos coéquipiers. Personne d'autre ne peut vous dire la bonne réponse. Cependant, si j'ose lire entre les lignes, le fait que vous appeliez ce style "mauvais" donne quelques informations qui suggèrent qu'il vaut mieux y aller lentement. Très peu de styles de codage sont en fait "mauvais". Il y en a que je n'utiliserais pas moi-même, mais ils ont toujours une rime ou une raison. Cela suggère, pour moi, qu'il y a plus dans l'histoire que vous n'en avez vu jusqu'à présent. Demander serait un appel très sage. Quelqu'un peut savoir quelque chose que vous ne connaissez pas.
Je suis tombé sur cela, personnellement, lors de ma première incursion dans le codage critique en temps réel. J'ai vu un code comme celui-ci:
lockMutex(&mutex);
int rval;
if (...)
{
...
rval = foo();
}
else
{
...
rval = bar();
}
unlockMutex(&mutex);
return rval;
Étant le développeur brillant et brillant OO C++ que j'étais, je les ai immédiatement dénoncés sur les risques de bogues qu'ils avaient en verrouillant et déverrouillant manuellement les mutex, plutôt qu'en utilisant RAII . J'ai insisté pour dire que c'était mieux:
MutexLocker lock(mutex);
if (...)
{
...
return foo();
}
else
{
...
return bar();
}
Beaucoup plus simple et c'est plus sûr, non?! Pourquoi exiger que les développeurs se souviennent de déverrouiller leurs mutex sur tous les chemins de flux de contrôle lorsque le compilateur peut le faire pour vous!
Eh bien, ce que j'ai découvert plus tard, c'est qu'il y avait une raison procédurale à cela. Nous avons dû confirmer que, effectivement, le logiciel fonctionnait correctement et qu'il y avait une liste finie d'outils que nous étions autorisés à utiliser. Mon approche a peut-être été meilleure dans un environnement différent, mais dans l'environnement dans lequel je travaillais, mon approche multiplierait facilement la quantité de travail impliquée dans la vérification de l'algorithme décuplée parce que je viens d'apporter un concept C++ de RAII dans une section de code qui était tenu à des normes qui étaient vraiment plus adaptées à la pensée de style C.
Donc, ce qui me paraissait mauvais, carrément dangereux, le style de codage pour moi était en fait bien pensé et ma "bonne" solution était en fait la dangereuse qui allait causer des problèmes en cours de route.
Alors demandez autour. Il y a sûrement un développeur senior qui peut travailler avec vous pour comprendre pourquoi ils le font de cette façon. Ou, il y a un développeur senior qui peut vous aider à comprendre les coûts et les avantages d'un refactor dans cette partie du code. Quoi qu'il en soit, demandez autour de vous!
Honnêtement, pensez-vous qu'avoir des fonctions difficiles à utiliser, avec 300 lignes, n'est qu'une question de style? Donc, suivre le mauvais exemple pourrait garder le programme global dans un meilleur état en raison de la cohérence? Je suppose que vous ne le croyez pas, sinon vous n'auriez pas posé cette question ici.
Je suppose que ces fonctions sont si longues car dans notre entreprise, il y a beaucoup de programmeurs médiocres qui empilent simplement des fonctionnalités sur des fonctionnalités, sans se soucier de la lisibilité, de la qualité du code, de la dénomination appropriée, des tests unitaires, de la refactorisation, et ils n'ont jamais appris à créer des abstractions appropriées . Vous devez décider par vous-même si vous voulez suivre ce troupeau ou si vous voulez être un meilleur programmeur.
Addendum, en raison des commentaires: "300 lignes" et "difficile à utiliser" sont des indications solides de mon humble avis pour un mauvais code. D'après mon expérience, il est très peu probable qu'il existe une "raison technique cachée" pour laquelle un tel code ne peut pas être implémenté d'une manière plus lisible, comparable à l'exemple de la réponse de Cort Ammon. Cependant, je suis d'accord avec Cort, vous devriez en discuter avec les responsables de l'équipe - non pas pour trouver des raisons obscures pour lesquelles le code ou ce "type de style" ne peut pas être changé, mais pour savoir comment le code peut être refactorisé en toute sécurité sans casser les choses. .
Non.
Dans le livre Programmeur Pragmatique l'auteur parle de la Théorie de la Fenêtre Brisée .
Cette théorie énonce:
Prenons un bâtiment avec quelques fenêtres cassées. Si les fenêtres ne sont pas réparées, les vandales ont tendance à briser quelques fenêtres de plus. Finalement, ils peuvent même pénétrer dans le bâtiment, et s'il n'est pas occupé, peut-être devenir des squatters ou des feux légers à l'intérieur.
Ou pensez à un trottoir. De la litière s'accumule. Bientôt, plus de déchets s'accumulent. Finalement, les gens commencent même à laisser des sacs d'ordures dans les restaurants à emporter ou même à s'introduire dans les voitures.
Dans le livre, l'auteur écrit un parallèle entre cette théorie et le code. Une fois que vous avez trouvé un code comme celui-ci, vous vous arrêtez et vous posez cette même question.
Et la réponse est: non.
Une fois que vous quittez cette fenêtre cassée - dans notre cas, un mauvais code - cela créera l'effet que tout le monde laissera des fenêtres cassées derrière.
Et un jour, le code s'effondrera.
Donnez une copie de Clean Code et Clean Coder à tout le monde.
Et pendant que vous êtes dans le sujet, une copie de TDD est également une bonne chose.
Oui, allez-y. Structure! = Style
Vous parlez de structure, pas de style. Les directives de style ne prescrivent pas (généralement) la structure, car la structure est généralement choisie pour sa pertinence pour un problème spécifique, et non pour une organisation.
Faites attention
Sachez simplement que vous ne causez pas de conséquences négatives dans d'autres domaines qui ne vous sont peut-être pas venus à l'esprit. Par exemple,
- Assurez-vous de ne pas compliquer les différences ou les fusions de code car vous avez effacé toute ressemblance avec le code existant.
- Assurez-vous que les flux d'exception bouillonnent correctement et que les traces de pile ne sont pas polluées par un énorme tas de bêtises illisibles.
- Assurez-vous de ne pas exposer accidentellement des points d'entrée publics qui pourraient causer des problèmes s'ils étaient appelés directement (ne les placez pas sur la carte et/ou ne les exportez pas).
- Ne pas encombrer l'espace de noms global, par ex. si vos petites fonctions nécessitent toutes une sorte de contexte global qui a été précédemment déclaré dans la portée locale de la fonction.
- Assurez-vous de regarder tous les journaux et demandez-vous si vous faisiez partie de l'équipe de support si les journaux générés par votre code seraient confus lorsqu'ils sont entrelacés avec les journaux de tout code que vous ne touchez pas.
- Assurez-vous que adhérez au style existant, par ex. même s'ils utilisent la vieille école notation hongroise et cela fait saigner les yeux, restez cohérent avec la base de code générale. La seule chose plus douloureuse que la lecture de la notation hongroise est la lecture de code qui utilise une douzaine de types de notation différents selon qui a écrit quoi.
Sois gentil
N'oubliez pas que vous faites partie d'une équipe, et bien qu'un bon code soit important, il est également très important que les membres de votre équipe soient en mesure de conserver ce que vous avez écrit lorsque vous partez en vacances. Essayez de vous en tenir à un flux qui aura du sens pour les personnes habituées à l'ancien style. Ce n'est pas parce que vous êtes le gars le plus intelligent de la pièce que vous devriez parler au-dessus de tout le monde!
Je ne vois pas cela comme une convention de code. Je vois cela comme quelqu'un ne comprenant pas comment écrire du code maintenable qui est facile à comprendre. Je décomposerais votre code en différentes fonctions en suggérant et en informant votre équipe des avantages de le faire tout en essayant de comprendre pourquoi ils estiment que les fonctions de 300 lignes sont acceptables. Je serais très intéressé d'entendre leur raisonnement.
La réponse se trouve dans la révision du code.
La vraie question est de savoir si vous mettez du code bien factorisé, allez-vous être le seul à vouloir travailler avec lui?
Comme la plupart des gens ici, je crois que 300 fonctions de ligne sont une abomination. Cependant, emmener Windex dans une décharge ne fera pas beaucoup de bien. Le problème n'est pas le code, ce sont les codeurs.
Avoir raison n'est pas suffisant. Vous devez vendre des gens sur ce style. Au moins en le lisant. Si vous ne vous retrouvez pas comme ce pauvre gars: licencié parce que vos compétences sont trop loin au-dessus de vos collègues
Commencer petit. Demandez autour de vous et découvrez si quelqu'un d'autre préfère les petites fonctions. Mieux encore, fouillez la base de code et voyez si vous pouvez déterminer qui écrit les plus petits (vous pouvez constater que le code le plus laid est le code le plus ancien et les codeurs actuels écrivent un meilleur code). Parlez-leur de cela et voyez si vous avez un allié. Demandez-leur s'ils connaissent quelqu'un d'autre qui ressent la même chose. Demandez-leur s'ils connaissent quelqu'un qui déteste les petites fonctions.
Rassemblez ce petit groupe et parlez d'apporter des changements. Montrez-leur le type de code que vous souhaitez écrire. Assurez-vous qu'ils peuvent le lire. Prenez toute objection au sérieux. Apportez les modifications. Faites approuver votre code. Vous avez maintenant le pouvoir d'une réunion derrière vous. Quelques-uns de plus et vous pouvez produire un document d'une page qui accepte explicitement le nouveau style que vous avez introduit.
Les réunions sont des choses étonnamment puissantes. Ils peuvent produire du poids. Le poids est ce que vous utiliserez pour combattre ceux qui s'opposent à ce mouvement. Et c'est ce que c'est à ce stade. Un mouvement. Vous vous battez pour le droit d'améliorer le statu quo. Les gens ont peur du changement. Vous aurez besoin de parler doucement, de cajoler et de pousser. Mais avec un peu de chance, vous aurez raison d'être accepté.
Avant de déclarer que les pratiques sont mauvaises, je ferais d'abord un pas vers la compréhension de la raison des grandes méthodes et autres pratiques qui pourraient apparaître comme mauvaises.
Ensuite, vous devez vous assurer que la couverture du test est assez élevée ou très élevée (autant que vous pouvez le faire sans refactorisation majeure). Si ce n'est pas le cas, je travaillerais à rendre la couverture très élevée même si vous n'avez pas écrit le code. Cela aide à établir des relations et la nouvelle équipe vous prendra plus au sérieux.
Une fois que vous avez couvert ces bases, personne de bon sens ne vous défierait. En tant qu'élément bonus, faites un micro-benchmarking et cela ajoutera vraiment à votre cas.
Souvent, la façon dont vous Word vous aide à changer la culture du code. Mener par l'exemple. Ou encore mieux, attendez un morceau de code que vous pouvez écrire - refactor et test unitaire de l'enfer et alto - vous serez entendu.
Ce type de question est fondamentalement "veuillez lire attentivement mes coéquipiers". Les personnes aléatoires sur Internet ne peuvent pas faire cela, donc toutes les réponses que vous obtiendrez ne sont que des opinions personnelles des gens sur le style de codage. Le consensus est que des méthodes plus courtes sont préférables, mais vous semblez déjà le penser vous-même, donc pas besoin de le répéter.
Ainsi, la base de code actuelle semble utiliser un style de codage différent de celui que vous préférez. Que devrais tu faire? Vous devez d'abord comprendre:
- S'agit-il d'une décision de conception délibérée appuyée par votre équipe actuelle?
- Veulent-ils que vous suiviez ce style?
Il n'y a qu'une seule façon de le savoir. Demandez.
Il pourrait y avoir plusieurs raisons d'avoir de longues fonctions. Cela pourrait être dû au fait que l'équipe pense que les fonctions longues sont meilleures que les fonctions courtes multiples. Cela pourrait également être dû au fait qu'il s'agit d'un code hérité, et l'équipe préfère que le nouveau code suive une conception plus propre. Donc soit le choix pourrait vous poser des problèmes en tant que développeur, si vous ne parlez pas à l'équipe et ne comprenez pas son raisonnement.
Parfois, vous devez suivre le courant.
Comme vous l'avez dit, vous avez été chargé d'implémenter une fonction dans une base de code de travail existante.
Indépendamment du gâchis, et je comprends qu'il est tentant de le nettoyer. mais dans le monde des affaires, vous n'avez pas toujours la possibilité de refactoriser le code.
Je dirais simplement faire ce qu'on vous a demandé de faire et passer à autre chose.
Si vous pensez que cela vaut la peine d'être refactorisé ou réécrit, vous devez en parler pour discuter avec l'équipe.
Il existe différents niveaux de "style".
À un niveau, faisant généralement partie des conventions de codage, cela signifie où placer les espaces blancs, les lignes vides, les crochets et comment nommer les choses (casse mixte, traits de soulignement, etc.).
À un autre niveau se trouve le modèle de programmation, parfois des choses comme éviter la statique, ou utiliser des interfaces sur des classes abstraites, comment exposer les dépendances, peut-être même éviter certaines fonctionnalités du langage ésotérique.
Ensuite, il y a les bibliothèques et les cadres utilisés par le projet.
Parfois, il y aura une limite maximale sur la taille de la fonction. Mais il y a rarement une limite minimale! Donc, vous devriez savoir laquelle de ces choses les pouvoirs qui sont importants, et essayer de respecter cela.
Vous devez savoir si l'équipe est opposée à la refactorisation du code existant, ce qui devrait être fait indépendamment de l'ajout de nouveau code lorsque cela est possible.
Cependant, même s'ils ne veulent pas refactoriser le code existant, vous pouvez être en mesure d'introduire certaines couches dans les abstractions pour le nouveau code que vous ajoutez, ce qui signifie qu'avec le temps, vous pouvez développer une meilleure base de code et peut-être migrer l'ancien code comme son entretien nécessite.