Suivez-vous la convention de nommage du programmeur d'origine?

Question

Si vous prenez le projet de quelqu'un pour faire de simples mises à jour, suivez-vous la convention de dénomination? Je viens de recevoir un projet dans lequel le programmeur précédent utilisait la notation hongroise partout. Notre produit de base a une norme de dénomination, mais de nombreuses personnes ont créé des rapports personnalisés au fil des ans et ont fait ce qu'elles souhaitaient.

Je n'ai pas le temps de changer tous les noms de variables déjà dans le code.

Je suis enclin à la lisibilité juste pour continuer avec leur convention de nommage.

Answer 1

Oui, je le fais. Cela facilite la tâche des personnes qui en héritent après vous. J'essaie de nettoyer un peu le code pour le rendre plus lisible s'il est vraiment difficile à comprendre.

Answer 2

Je conviens que suggérer de laisser le code tel que l'auteur l'a écrit est acceptable tant que le code est cohérent en interne. Si le code est difficile à suivre en raison d'un manque de cohérence, vous avez la responsabilité de: futur responsable (probablement vous) pour que ce soit plus clair.

Si vous passez 40 heures à déterminer le rôle d’une fonction car elle utilise des variables mal nommées, etc., vous devriez refactoriser / renommer pour plus de clarté / ajouter un commentaire / faire tout ce qui est approprié à la situation.

Cela dit, si le seul problème est que le style généralement cohérent utilisé par l'auteur diffère de la norme de la société ou de ce à quoi vous êtes habitué, je pense que vous perdez votre temps à tout renommer. En outre, vous risquez de perdre une source d'expertise si l'auteur d'origine est toujours disponible pour des questions car il ne reconnaîtra plus le code.

Answer 3

Si vous ne modifiez pas tout le code existant en fonction de votre norme, je dirais que vous devez vous en tenir aux conventions d'origine tant que vous modifiez ces fichiers. Mélanger deux styles de code dans le même fichier détruit tout avantage qu'un style de code cohérent aurait, et le type suivant devrait constamment se demander "qui a écrit cette fonction, comment elle s'appellera - FooBar () ou fooBar ()? "

Ce genre de choses devient encore plus délicat lorsque vous importez des bibliothèques tierces - vous ne voulez pas les réécrire, mais leur style de code peut ne pas correspondre à votre vôtre. En fin de compte, vous vous retrouverez avec plusieurs conventions de dénomination différentes, et il est préférable de tracer des lignes claires entre "notre code". et "leur code".

Answer 4

Souvent, apporter une modification globale à une base de code simplement pour se conformer au guide de style constitue simplement un moyen d'introduire de nouveaux bogues sans grande valeur ajoutée.

Cela signifie que vous devez soit:

1. Mettez à jour le code sur lequel vous travaillez pour qu'il soit conforme à la ligne directrice.

2. Utilisez les conventions du code pour faciliter les futurs efforts de maintenance.

Je recommanderais 2., mais la notation hongroise me saigne des yeux: p.

Answer 5

Si vous conservez du code que d'autres ont écrit et que d'autres personnes vont conserver après vous, vous devez à toutes les personnes concernées de ne pas apporter de modifications gratuites. Quand ils vont dans le système de contrôle du code source pour voir ce que vous avez changé, ils devraient voir ce qui était nécessaire pour résoudre le problème sur lequel vous travailliez, et non pas un million de diffs parce que vous avez effectué un tas de recherches globales et remplacé ou reformaté le code. correspond à votre convention d'appariement préférée.

Bien sûr, si le code d'origine est vraiment nul, tous les paris sont valables.

Answer 6

Généralement, oui, je privilégierais la convention et la lisibilité des normes dans ce scénario. Personne n'aime cette réponse, mais il est judicieux de conserver le code maintenable à long terme.

Quand un bon programmeur lit le code, il devrait pouvoir analyser les noms de variable et en garder la trace dans sa tête - tant que leur cohérence est cohérente, du moins dans le fichier source. Mais si vous cassez cette cohérence, cela forcera probablement le programmeur à lire le code à subir une dissonance cognitive, ce qui compliquera la tâche. Ce n'est pas un meurtrier - les bons programmeurs réussiront, mais ils maudiront votre nom et vous posteront probablement sur TheDailyWTF .

Answer 7

Je continuerais certainement à utiliser la même convention d'appellation, car cela maintiendrait le code cohérent (même s'il est toujours laid) et plus lisible que le mélange des conventions d'appellation des variables. Les cerveaux humains semblent être plutôt doués pour la reconnaissance des formes et vous ne voulez pas vraiment lancer une courbe au cerveau en brisant gratuitement ladite forme.

Cela dit, je ne suis qu'un peu de la notation hongroise, mais si c'est ce que vous avez à travailler avec ...

Answer 8

Si le fichier ou le projet est déjà écrit en utilisant un style cohérent, vous devez essayer de suivre ce style, même s'il est en conflit / contradictoire avec votre style existant. L'un des principaux objectifs d'un style de code est la cohérence. Par conséquent, si vous introduisez un style différent dans un code déjà cohérent (en lui-même), vous perdez cette cohérence.

Si le code est mal écrit et nécessite un certain nettoyage afin de le comprendre, le nettoyage du style devient une option plus pertinente, mais vous ne devez le faire que si cela est absolument nécessaire (surtout s'il n'y a pas de tests unitaires). vous avez la possibilité d'introduire des changements inattendus.

Answer 9

Absolument, oui. Le seul cas où je ne pense pas qu'il soit préférable de suivre la convention de nommage du programmeur d'origine est lorsque le programmeur d'origine (ou les développeurs ultérieurs qui ont modifié le code depuis) ??n'ont pas respecté les conventions de nommage cohérentes.

Answer 10

Oui. Je l'ai en fait écrit dans un document sur les normes. J'ai créé dans mon entreprise actuelle:

Le code existant remplace toutes les autres normes et pratiques (qu’il s’agisse de normes sectorielles ou de celles décrites dans ce document). Dans la plupart des cas, vous devez utiliser votre code pour qu'il corresponde au code existant dans les mêmes fichiers, pour deux raisons:

1. Pour éviter d’avoir plusieurs styles / modèles distincts au sein d’un même module / fichier (ce qui contredit l’objet des normes et gêne la maintenabilité).
2. L’effort de refactorisation du code existant risque d’être inutilement plus onéreux (long et propice à l’introduction de nouveaux bogues).

Answer 11

Personnellement, chaque fois que je prends en charge un projet qui a un schéma de nommage de variable différent, j'ai tendance à conserver le même schéma que celui utilisé par le précédent programmeur. La seule chose que je fais différemment concerne les nouvelles variables que j'ajoute, je mets un trait de soulignement avant le nom de la variable. De cette façon, je peux voir rapidement mes variables et mon code sans avoir à aller dans l'historique des sources et à comparer les versions. Mais quand il s'agit d'hériter de code ou de commentaires simplement illisibles, je les passe en revue et les nettoie du mieux que je peux sans réécrire le tout (c'est arrivé à cela). L’organisation est la clé pour avoir du code extensible!

Answer 12

si je peux lire le code, j'essaie de prendre les mêmes conventions si ce n’est pas lisible de toute façon, j’ai besoin de refactoriser et donc de le changer (en fonction de ce qui lui ressemble) considérable

Answer 13

Dépend. Si je construis une nouvelle application et que je vole le code d'une application héritée avec un nom de variable de merde, je vais le refactoriser une fois que je l'aurai dans mon application.

Answer 14

Oui .. Il est un peu plus frustrant que de se lancer dans une application qui a deux styles radicalement différents. Un projet sur lequel j'ai récemment travaillé avait deux manières différentes de manipuler des fichiers, deux manières différentes de mettre en place des écrans, deux structures de fond différentes. Le deuxième codeur est même allé jusqu'à intégrer les nouvelles fonctionnalités à une dll appelée à partir du code principal. Le maintien était cauchemardesque et j'ai dû apprendre les deux paradigmes et espérer que lorsque je travaillais dans une section, je travaillais avec la bonne.

Answer 15

Quand à Rome, faites comme les Romains.

(Sauf pour les noms de variables d'index, par exemple "iArrayIndex ++". Arrêtez de tolérer cette idiotie.)

Answer 16

Je pense que la correction d’un bogue est une intervention chirurgicale. Entrez, dérangez le moins possible, réparez-le, sortez, laissez le moins de traces possible de votre présence.

Answer 17

Oui, mais malheureusement, plusieurs développeurs avant moi n’avaient pas respecté cette règle et j’ai donc le choix entre plusieurs conventions de dénomination.

Mais parfois, nous avons le temps de remettre les choses à plat pour que ce soit beau et propre à la fin.

Answer 18

Si le code a déjà un style cohérent, y compris la dénomination, j'essaie de le suivre. Si les programmeurs précédents n'étaient pas cohérents, je me sens libre d'appliquer la norme de l'entreprise ou mes normes personnelles s'il n'y a pas de norme de l'entreprise.

Dans les deux cas, j'essaie de marquer les modifications que j'ai apportées en les encadrant de commentaires. Je sais qu'avec les systèmes CVS actuels, ce n'est souvent pas fait, mais je préfère quand même le faire.

Answer 19

Malheureusement, la plupart du temps, la réponse est oui. La plupart du temps, le code ne suit pas les bonnes conventions, il est donc difficile de suivre le précédent. Mais pour des raisons de lisibilité, il est parfois nécessaire de suivre le courant.

Cependant , s'il s'agit d'une application suffisamment petite, je peux refactoriser une grande partie du code existant pour "sentir". mieux, alors je le ferai. Ou, si cela fait partie d'une réécriture plus grande, je commencerai également à coder avec les normes de codage actuelles. Mais ce n’est généralement pas le cas.

Answer 20

S'il existe une norme dans l'application existante, je pense qu'il est préférable de la suivre. S'il n'y a pas de standard (onglets et espaces mélangés, accolades partout ... oh l'horreur), alors je fais ce que j'estime être le meilleur et je gère généralement le code existant via un outil de formatage (comme Vim). Je conserverai toujours le style de capitalisation, etc. du code existant s'il existe un style cohérent.

La seule exception à cette règle est que je n'utiliserai pas la notation hongroise à moins que quelqu'un ait une arme à la tête. Je ne prendrai pas le temps de renommer des éléments existants, mais tout ce que j'ajouterai ne créera pas de verrues hongroises.