Cela est devenu une grande frustration avec le code sur lequel je travaille actuellement; beaucoup de nos noms de variables sont courts et non descriptifs. Je suis le seul développeur qui reste sur le projet et il n'y a pas de documentation sur ce que font la plupart d'entre eux. Je dois donc passer plus de temps à rechercher ce qu'ils représentent.
Par exemple, je lisais un code qui met à jour la définition d’une surface optique. Les variables définies au début étaient les suivantes:
double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on
Peut-être que c'est juste moi, mais cela ne me dit essentiellement rien de ce qu'ils représentaient, ce qui rendait la compréhension du code plus difficile. Tout ce que je savais, c'est qu'il s'agissait d'une variable analysée dans une ligne spécifique d'une table spécifique, quelque part. Après quelques recherches, j'ai découvert ce qu'ils voulaient dire:
dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius
Je les ai renommés pour essentiellement ce que j'ai là-haut. Cela rallonge certaines lignes, mais j'estime que c'est un compromis équitable. Ce type de schéma de nommage est toutefois utilisé dans une grande partie du code. Je ne sais pas si c'est un artefact de développeurs qui ont appris à travailler avec des systèmes plus anciens, ou s'il y a une raison plus profonde derrière cela. Existe-t-il une bonne raison de nommer les variables de cette façon ou ai-je le droit de les mettre à jour avec des noms plus descriptifs au fur et à mesure que je les rencontre?
dK = conic constant
.