Question

Nous savons tous que le commentaire de notre code est un élément important du style de codage, car il permet de rendre notre code compréhensible pour la prochaine personne, voire pour nous-mêmes, dans 6 mois environ.

Cependant, parfois, un commentaire ne coupe pas la moutarde. Je ne parle pas de blagues évidentes ou de frustrations exagérées, je parle de commentaires qui semblent tenter d'expliquer, mais faites-le si mal qu'ils pourraient tout aussi bien ne pas être là. Les commentaires trop courts , trop cryptiques ou tout à fait faux .

En tant que récit cautonique, pouvez-vous partager une chose que vous avez vue et qui est vraiment aussi mauvaise , et si ce n'est pas évident, montrez le code auquel elle fait référence et signalez ce qui ne va pas ? Qu'est-ce que aurait dû y aller à la place?

Voir aussi:

Était-ce utile?

La solution

Juste les commentaires typiques du type Comp Sci 101:

$i = 0; //set i to 0

$i++; //use sneaky trick to add 1 to i!

if ($i==$j) { // I made sure to use == rather than = here to avoid a bug

Ce genre de chose.

Autres conseils

Les commentaires sur le passe-partout javadoc non remplis sont particulièrement inutiles. Ils consomment beaucoup d’écran sans rien apporter d’utile. Et le pire, c’est que là où un tel commentaire apparaît, des centaines d’autres se cachent derrière.

/**
 * Method declaration
 *
 *
 * @param table
 * @param row
 *
 * @throws SQLException
 */
void addTransactionDelete(Table table, Object row[]) throws SQLException {

Je me suis retrouvé en train d'écrire ce petit bijou auparavant:

//@TODO: Rewrite this, it sucks. Seriously.

Généralement, c’est bon signe que je suis arrivé au bout de ma session de codage pour la nuit.

// remember to comment code

wtf? : D

Quelque chose comme ça:

// This method takes two integer values and adds them together via the built-in
// .NET functionality. It would be possible to code the arithmetic function
// by hand, but since .NET provides it, that would be a waste of time
private int Add(int i, int j) // i is the first value, j is the second value
{
    // add the numbers together using the .NET "+" operator
    int z = i + j;

    // return the value to the calling function
    // return z;

    // this code was updated to simplify the return statement, eliminating the need
    // for a separate variable.
    // this statement performs the add functionality using the + operator on the two
    // parameter values, and then returns the result to the calling function
    return i + j;
}

Et ainsi de suite.

Chaque commentaire qui ne fait que répéter ce que dit le code est inutile. Les commentaires ne doivent pas me dire ce que le code fait. Si je ne connais pas suffisamment le langage de programmation pour comprendre ce qui se passe simplement en lisant le code, je ne devrais pas le lire du tout. Des commentaires comme

// Increase i by one
i++;

sont complètement inutiles. Je vois que je suis augmenté de un, c'est ce que dit le code, je n'ai pas besoin de commentaire pour ça! Les commentaires doivent être utilisés pour expliquer pourquoi quelque chose est fait (au cas où cela serait loin d’être évident) ou pourquoi quelque chose se ferait-il de cette façon et pas autrement (pour que je puisse comprendre certaines décisions de conception prises par un autre programmeur qui ne sont de loin pas évidentes à la fois). D'autres commentaires sont utiles pour expliquer un code compliqué, où il n'est absolument pas possible de déterminer ce qui se passe en examinant rapidement le code (par exemple, il existe des algorithmes complexes pour compter le nombre de bits définis dans un nombre; sinon, savoir ce que fait ce code, vous n’avez aucune chance de deviner ce qui se passe là-bas).

Thread.Sleep(1000); // this will fix .NET's crappy threading implementation

J'ai déjà travaillé sur un projet avec un étrange compilateur en C. Cela donnait une erreur sur un morceau de code valide, sauf si un commentaire était inséré entre deux instructions. J'ai donc changé le commentaire en:

// Do not remove this comment else compilation will fail.

Et cela a très bien fonctionné.

Je ne le crois pas. Je suis entré dans cette question après avoir eu 22 réponses, et personne n’a signalé le type de commentaire le moins utile:

commentaires erronés.

Il est déjà assez grave que des personnes écrivent des commentaires superflus qui entravent la compréhension du code, mais lorsque quelqu'un écrit un commentaire détaillé expliquant comment quelque chose fonctionne, il est soit faux en premier lieu, soit incorrect après que le code a été modifié sans changement. le commentaire (scénario beaucoup plus probable), c’est certainement le pire type de commentaire.

GhostDoc en propose d’autres très intéressants.

/// <summary>
/// Toes the foo.
/// </summary>
/// <returns></returns>
public Foo ToFoo()
// secret sauce
// Don't know why we have to do this
try
{
...some code...
}
catch
{
// Just don't crash, it wasn't that important anyway.
}

* soupir

Entré dans un fichier une fois. Des milliers de lignes de code, la plupart assez horribles. Variables mal nommées, conditionnelles difficiles sur les boucles et un commentaire enfoui au milieu du fichier.


   /* Hmmm. A bit tricky. */
//' OOOO oooo that smell!! Can't you smell that smell!??!??!!!!11!??/!!!!!1!!!!!!1

If Not Me.CurrentMenuItem.Parent Is Nothing Then
    For Each childMenuItem As MenuItem In aMenuItem.Children
        do something
    Next

    If Not Me.CurrentMenuItem.Parent.Parent Is Nothing Then
        //'item is at least a grand child
        For Each childMenuItem As MenuItem In aMenuItem.Children
            For Each grandchildMenuItem As MenuItem In childMenuItem.Children
                do something
            Next
        Next

        If Not Me.CurrentMenuItem.Parent.Parent.Parent Is Nothing Then
            //'item is at least a grand grand child
            For Each childMenuItem As MenuItem In aMenuItem.Children
                For Each grandchildMenuItem As MenuItem In childMenuItem.Children
                    For Each grandgrandchildMenuItem As MenuItem In grandchildMenuItem.Children
                        do something
                    Next
                Next
            Next

        End If
    End If
End If

Commentaires par défaut insérés par les IDE.

Le dernier projet WebSphere Application Developer sur lequel je travaillais comptait de nombreux développeurs et entrepreneurs en maintenance qui ne semblaient pas être dérangés par des centaines, voire des milliers de classes Java contenant ce genre de choses:

/**
 * @author SomeUserWhoShouldKnowBetter
 *
 * To change this generated comment edit the template variable "typecomment":
 * Window>Preferences>Java>Templates.
 * To enable and disable the creation of type comments go to
 * Window>Preferences>Java>Code Generation.
 */

Il y avait toujours une fraction de seconde entre penser que vous aviez trouvé un fichier source bien commenté et le réaliser, eh bien, c'est un autre commentaire par défaut, ce qui vous a obligé à utiliser SWEAR_WORD_OF_CHOICE .

J'ai vu ce commentaire hier dans une application C #:

//TODO: Remove this comment.

Mon commentaire préféré de tous les temps.

/* our second do loop */
do {

Celui qui l'a écrit - vous savez qui vous êtes.

un très grand projet de moteur de base de données en C il y a de nombreuses années - des milliers de lignes de code avec des noms de variables courts et mal orthographiés, et aucun commentaire ... le commentaire suivant est apparu:

//if you get here then you really f**ked

à ce moment-là, je pense que nous le savions déjà!

Dans une énorme application VB5

dim J
J = 0 'magic
J = J 'more magic
for J=1 to 100
...do stuff...

La référence est évidemment THIS ... et oui, l'application sans ces deux lignes échoue au moment de l'exécution avec un code d'erreur inconnu. Nous ne savons toujours pas pourquoi.

Extrait de l'un de mes messages sur le blog :

  

En nettoyant une partie du code source de l'un des projets que je gère, je suis tombé sur les commentaires suivants:

/*
   MAB 08-05-2004: Who wrote this routine? When did they do it? Who should 
   I call if I have questions about it? It's worth it to have a good header
   here. It should helps to set context, it should identify the author 
   (hero or culprit!), including contact information, so that anyone who has
   questions can call or email. It's useful to have the date noted, and a 
   brief statement of intention. On the other hand, this isn't meant to be 
   busy work; it's meant to make maintenance easier--so don't go overboard.

   One other good reason to put your name on it: take credit! This is your
   craft
*/

puis un peu plus bas:

#include "xxxMsg.h" // xxx messages
/*
   MAB 08-05-2004: With respect to the comment above, I gathered that
   from the filename. I think I need either more or less here. For one
   thing, xxxMsg.h is automatically generated from the .mc file. That might
   be interesting information. Another thing is that xxxMsg.h should NOT be
   added to source control, because it's auto-generated. Alternatively, 
   don't bother with a comment at all.
*/

et puis encore:

/*
   MAB 08-05-2004: Defining a keyword?? This seems problemmatic [sic],
   in principle if not in practice. Is this a common idiom? 
*/

AHHHRRRGGHHH Je viens de trouver cela dans un code ancien, pariez que le gars pensait qu'il était assez drôle

private
  //PRIVATE means PRIVATE so no comments for you
  function LoadIt(IntID: Integer): Integer;

Le pire commentaire est celui qui donne une mauvaise explication de ce que fait le code. C’est pire qu’aucun commentaire.

J'ai vu ce genre de chose dans le code avec trop de commentaires (cela ne devrait pas être là car le code est assez clair en soi), et cela arrive surtout lorsque le code est mis à jour (refactorisé, modifié, etc.) mais les commentaires ne sont pas mis à jour avec.

Une bonne règle est la suivante: écrivez uniquement des commentaires pour expliquer la raison pour laquelle le code agit, et non ce que il fait.

Il faudrait certainement que les commentaires remplacent le traitement des erreurs.

if(some_condition){
    do_stuff();
}
else{
    //An error occurred!
}

Je viens de trouver celui-ci, écrit sur la ligne avant une ligne de code commentée:

//This causes a crash for some reason. I know the real reason but it doesn't fit on this line.

Application 100k LOC qui a été transférée de vb6 vers vb.net. Il semble qu'un développeur précédent ait mis un en-tête de commentaire sur une méthode, puis copié et collé le commentaire exact sur chaque méthode qu'il a ensuite écrite. Des centaines de méthodes et chacune d’elles mal commentée ...

Quand j'ai vu ça pour la première fois, j'ai ri ... 6 mois plus tard, la blague est mince.

Ceci est un exemple absolument réel tiré d'un déclencheur de base de données:

/******************************************************************************
   NAME:       (repeat the trigger name)
   PURPOSE:    To perform work as each row is inserted or updated.
   REVISIONS:
   Ver        Date        Author           Description
   ---------  ----------  ---------------  ------------------------------------
   1.0        27.6.2000             1. Created this trigger.
   PARAMETERS:
   INPUT:
   OUTPUT:
   RETURNED VALUE:
   CALLED BY:
   CALLS:
   EXAMPLE USE:
   ASSUMPTIONS:
   LIMITATIONS:
   ALGORITHM:
   NOTES:
******************************************************************************/
/** function header comments required to pass checkstyle */

Les deux commentaires les plus inutiles que j'ai jamais vus ...

try
{
  ...
}
catch
{
  // TODO: something catchy
}

J'ai posté celui-ci au Daily WTF également, je vais donc le réduire au commentaire ...

  // TODO: The following if block should be reduced to one return statememt:
  // return Regex.IsMatch(strTest, NAME_CHARS);
  if (!Regex.IsMatch(strTest, NAME_CHARS))
    return false;
  else
    return true;

Celui que je n'ai jamais trouvé très utile:

<!--- Lasciate ogne speranza, voi ch'intrate --->
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top