Si vous êtes programmeur, il existe de nombreuses pratiques que vous pouvez détester.
Valeurs codées en dur. Double logique. Hiérarchies d'héritage complexes. Mais les commentaires devraient-ils figurer sur cette liste?
Il y a longtemps, à l'époque de la programmation préhistorique, l'écriture de commentaires était considérée comme une partie obligatoire de l'écriture de code. Lorsque vous avez écrit le code, il était rempli de commentaires courts et précis. Ensuite, le code propre et la programmation agile ont commencé à régner sur le monde. Les puristes ont crié sur les dangers des commentaires qui remplissaient du code non structuré et vulnérable. Soudain, les commentaires sont devenus une erreur, un anti-modèle, une collection de mensonges.
De nombreux développeurs se sont sentis acculés.
Mais le choix est-il si évident? Ou y a-t-il encore un moyen d'écrire des commentaires et en même temps de se respecter en se levant le matin? Pour trouver la réponse, regardons comment un code terrible est commenté et comment même un mauvais commentaire peut sauver des vies.
Commentaires paresseux
, , .
, , :
double delta = h*h-r1*r1;
double r2 = Math.Sqrt(delta);
, , . , , , :
// Calculate side length using the Pythagorean Theorem
// and put the value into variable "r2"
double delta = h*h-r1*r1;
double r2 = Math.Sqrt(delta);
- . .
. , :
double lengthSideB = Math.Sqrt(
Math.Pow(hypotenuse,2) - Math.Pow(lengthSideA,2);
)
:
double sideA = Pythagoras.GetLengthOfSide(hyptenuse, sideB);
? ! - , , . , . , . - - .
. , , , . , - - . , , . , . , . :
/**
* Constructor.
*
* @param name (required) brand name of the product. Must have
* content. Length must be in range 1..50.
* @param price (optional) purchase price of the product.
* @param units (required) number of units currently in stock.
* Can not be less than 0.
*/
public Product(string name, decimal price, integer units)
{
...
}
, , . - , . . , , .
. , . . . . , , - . API. , , . . - , . , API , , , . . , - . , . .
« - » - , .
. , - :
// to match ITG1's late arrows. -K
GlobalOffsetSeconds=-0.006
, - , . - , , , , . , , , . . , , , . , - , , , , ? - , , , , , .
, , , , . , , , . , . - , - .
“I spent some time this weekend looking at very well-named, very clean, uncommented code implementing a research algorithm. I’m high-level familiar with it, the guy sitting next to me was the inventor, and the code was written a few years ago by someone else. We could barely follow it.” — Paul Nathan
, , . , , , . . , . , , . .
, . . :
( )
( )
( IDE)
La question principale est simple. Vaut-il la peine de payer pour les commentaires? Les opinions diffèrent, mais si vous utilisez les commentaires de manière réfléchie et intelligente - si vous les utilisez pour réduire la charge cognitive de votre code, plutôt que pour contrer les mauvaises pratiques - ils peuvent ajouter de la valeur même au code le plus propre.