¿Cuál es el comentario menos útil que has visto? [cerrado]

Question

Todos sabemos que comentar nuestro código es una parte importante del estilo de codificación para hacer que nuestro código sea comprensible para la siguiente persona que nos acompañe, o incluso para nosotros mismos en aproximadamente 6 meses.

Sin embargo, a veces un comentario simplemente no corta la mostaza. No estoy hablando de bromas obvias o de frustraciones desahogadas, estoy hablando de comentarios que parecen estar haciendo un intento de explicación, pero hazlo tan mal que bien podría no estar allí. Los comentarios que son demasiado cortos , son demasiado crípticos , o son simplemente erróneos .

Como un cuento cautonario, podrías compartir algo que hayas visto que realmente fue tan malo , y si no es obvio, muestra el código al que se refiere y señala qué tiene de malo ? ¿Qué debería haber entrado allí?

Ver también:

• Cuando NO comentar tu código
• ¿Le gustan sus comentarios? (Mejores Prácticas)
• ¿Cuál es el mejor comentario? en el código fuente que has encontrado?

Answer 1

Solo los comentarios típicos del tipo 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

Ese tipo de cosas.

Answer 2

Los comentarios de javadoc sin rellenar son particularmente inútiles. Ellos consumen una gran cantidad de pantalla de bienes raíces sin aportar nada útil. Y lo peor es que donde aparece un comentario de este tipo, cientos de otros seguramente están al acecho detrás.

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

Answer 3

Me he encontrado escribiendo esta pequeña joya antes:

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

Por lo general, es una buena señal de que he llegado al final de mi sesión de codificación para la noche.

Answer 4

// remember to comment code

wtf? : D

Answer 5

Algo como esto:

// 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;
}

Y así sucesivamente.

Answer 6

Todo comentario que simplemente repita lo que dice el código es inútil. Los comentarios no deben decirme lo que hace el código. Si no conozco el lenguaje de programación lo suficiente como para entender lo que está pasando con solo leer el código, no debería leer ese código en absoluto. Comentarios como

// Increase i by one
i++;

son completamente inútiles. Veo que i se incrementa en uno, eso es lo que dice el código, ¡no necesito un comentario para eso! Los comentarios deben usarse para explicar por qué se hace algo (en caso de que esté lejos de ser obvio) o por qué se haga de esa manera y no de otra manera (para que pueda Comprenda ciertas decisiones de diseño que hizo otro programador que, de lejos, no son obvias a la vez. Otros comentarios son útiles para explicar el código complicado, donde no es absolutamente posible determinar lo que está sucediendo con un rápido vistazo al código (por ejemplo, hay algoritmos complejos para contar el número de bits establecidos en un número; si no lo hace sabe lo que hace este código, no tiene ninguna posibilidad de adivinar qué ocurre allí).

Answer 7

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

Answer 8

Una vez trabajé en un proyecto con un extraño compilador de C. Dio un error en una pieza de código válida a menos que se insertara un comentario entre dos declaraciones. Así que cambié el comentario a:

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

Y funcionó muy bien.

Answer 9

No lo creo. Llegué a esta pregunta después de que tenía 22 respuestas, y nadie señaló el tipo de comentario menos útil posible:

comentarios que están mal.

Ya es bastante malo que las personas escriban comentarios superfluos que se interpongan en la forma de entender el código, pero cuando alguien escribe un comentario detallado que explica cómo funciona algo, y en primer lugar es incorrecto o incorrecto después de que se cambió el código sin cambiarlo. El comentario (escenario mucho más probable), ese es definitivamente el peor tipo de comentario.

Answer 10

A GhostDoc se le ocurren algunas interesantes por sí mismas.

/// <summary>
/// Toes the foo.
/// </summary>
/// <returns></returns>
public Foo ToFoo()

Answer 11

// secret sauce

Answer 12

// Don't know why we have to do this

Answer 13

try
{
...some code...
}
catch
{
// Just don't crash, it wasn't that important anyway.
}

* suspiro

Answer 14

Encontré un archivo una vez. Miles de líneas de código, la mayoría bastante horrendas. Variables mal nombradas, condicionales difíciles en los bucles y un comentario enterrado en medio del archivo.

   /* Hmmm. A bit tricky. */

Answer 15

//' 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

Answer 16

Comentarios predeterminados insertados por IDEs.

El último proyecto en el que trabajé y que usé WebSphere Application Developer tenía muchos desarrolladores y contratistas de mantenimiento que no parecían molestados por los cientos, sino miles de clases de Java que contenían datos similares a estos:

/**
 * @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.
 */

Siempre hubo una fracción de segundo entre pensar que realmente encontraste un archivo fuente bien comentado y darte cuenta de que, sí, es otro comentario predeterminado, que te obligó a usar SWEAR_WORD_OF_CHOICE .

Answer 17

Vi este comentario ayer en una aplicación de C #:

//TODO: Remove this comment.

Answer 18

Mi comentario favorito de todos los tiempos.

/* our second do loop */
do {

Quien lo escribió, tú sabes quién eres.

Answer 19

un proyecto de motor de base de datos muy grande en C hace muchos muchos años: miles de líneas de código con nombres de variables cortos y mal escritos, y sin comentarios ... hasta el fondo de las condiciones de miles de líneas anidadas en el módulo siguiente comentario apareció:

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

en ese momento, creo que ya lo sabíamos!

Answer 20

En una gran aplicación VB5

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

La referencia es obviamente THIS ... y sí, la aplicación sin esas dos líneas falla en tiempo de ejecución con un código de error desconocido. Todavía no sabemos por qué.

Answer 21

Tomado de uno de mis publicaciones del blog :

  

En el proceso de limpiar parte del código fuente de uno de los proyectos que administro, encontré los siguientes comentarios:

/*
   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
*/

y luego un poco más abajo:

#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.
*/

y luego otra vez:

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

Answer 22

AHHHRRRGGHHH Acabo de encontrar esto en un código antiguo, apuesto a que el chico pensó que era muy gracioso

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

Answer 23

El peor comentario es uno que da una explicación incorrecta de lo que hace el código. Eso es peor que ningún comentario en absoluto.

He visto este tipo de cosas en el código con demasiados comentarios (que no deberían estar allí porque el código es suficientemente claro por sí solo), y ocurre principalmente cuando el código se actualiza (refaccionado, modificado, etc.) pero los comentarios no se actualizan junto con él.

Una buena regla general es: solo escriba comentarios para explicar por qué el código está haciendo algo, no lo que hace.

Answer 24

Definitivamente tendría que haber comentarios que sustituyan al manejo de errores.

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

Answer 25

Encontré este, escrito en la línea antes de una línea de código comentada:

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

Answer 26

Aplicación de LOCk de 100k que se portó de vb6 a vb.net. Parece como si un desarrollador anterior hubiera puesto un encabezado de comentario en un método y luego hubiera copiado y pegado el comentario exacto en cada método que escribió a partir de ese momento. Cientos de métodos y cada uno comentó incorrectamente ...

Cuando lo vi por primera vez, me reí ... 6 meses después, la broma se está agotando.

Answer 27

Este es un ejemplo absolutamente real de un activador de base de datos:

/******************************************************************************
   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:
******************************************************************************/

Answer 28

/** function header comments required to pass checkstyle */

Answer 29

Los dos comentarios más inútiles que he visto ...

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

También publiqué este en el Daily WTF, así que lo recortaré solo al comentario ...

  // 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;

Answer 30

Una que nunca he encontrado muy útil:

<!--- Lasciate ogne speranza, voi ch'intrate --->