¿El código comentado es siempre malo? [duplicar]

El beneficio de # ifdef's en lugar de comentarlo, es que (en proyectos grandes) puede tener las definiciones enumeradas en un archivo de configuración o de marca, y por lo tanto no tiene que ir manualmente a hacer comentarios, compile, y luego comentarlos nuevamente si está en muchos lugares. La desventaja de esto es que cambiar los DEFINES del proyecto generalmente significa reconstruir todo el asunto, no solo los archivos modificados.

Aunque ... Creo que el "código comentado es algo malo" realmente se refiere al código muerto que las personas simplemente no querían eliminar por el motivo que fuera (el temor de tirar algo que he pasado tiempo en quizás?). No se trata realmente de la situación que tienes a tu favor.

Si está comentado, puede pudrirse: cuando de repente decides que lo necesitas de nuevo, te das cuenta de que ya no se compila, o que hay que reescribirlo para que encaje con otras cosas que han cambiado mientras tanto.

Si deja el código adentro, pero de tal manera que el compilador pueda optimizarlo si no es necesario, entonces se beneficiará de mantener el código actualizado y sin tener que sufrir el tamaño binario añadido o el rendimiento en tiempo de ejecución.

Por ejemplo, en C, esto está en riesgo de pudrición:

/*
doSomeDebugStuff();
*/

Y así es esto:

#if 0
doSomeDebugStuff();
#endif

Pero esto es bueno, ya que el compilador siempre verifica la validez, pero es probable que se optimice:

if (0)
{
  doSomeDebugStuff();
}

Editar: como lo señalan otros, es mejor utilizar un símbolo significativo en lugar de 0 para la prueba.

Creo que se debe hacer una distinción entre el código comentado que está obsoleto y el código que se usa solo en una compilación de depuración (u otra compilación "especial" compilada condicionalmente). Esta última es una práctica común, y no hay nada malo en ello.

El primero no debería estar presente en una base de origen, ya que el sistema de control de versiones realiza un seguimiento de las cosas obsoletas, si alguna vez desea recuperarlo.

// The problem with commented out code is that it can hide what you're actually
// trying to say in a wall of text.  Syntax highlighting may help, but you're 
// still left with this huge ginormous wall of text in front of you, searching
// through it for what the actual answer is. You'd think that mentally it'd be 
// really easy to disregard the comments, but in actual usage, it's a lot harder
// than a one word answer that can tell you what you're looking for. It's tough.
/* Sometimes they'll even through you off with different comments. */ Yes.
// It's really tough to deal with people that don't like to use source control, 
// that would rather comment lines and lines of code instead of deleting the 
// code and checking in revision.  Cue irrelevant paragraph about the reason why 
// I wrote this instead of just deleting the entire block and replacing it 
// with my intention. Maybe I was hedging my bets? Cue misspelled wrod.  

Casi no hay "siempre" en la codificación :) Si conoce las razones detrás de una guía y tiene una buena razón para romperla, hágalo.

Por ejemplo, comento el código cuando hago "kamikaze-refactoring" y necesito un recordatorio visual para agregar cosas o recordar cómo funcionó el código antiguo por un tiempo. Es crucial en casos como este que elimines los comentarios más adelante, pero de lo contrario simplemente desordenarán tu código.

A veces, pones código en tus comentarios para mostrar cómo usar una clase, esto es muy diferente del código de comentario que solía ejecutarse.

Hago muchas revisiones de código y encuentro que no hay una excusa real para el código comentado, independientemente de la razón. Si está utilizando el código comentado para fines de depuración, puede crear un mecanismo de seguimiento que está deshabilitado en el modo de lanzamiento o tiene niveles de seguimiento (siempre es bueno poder rastrear en una versión de lanzamiento) o simplemente puede usar un depurador.

El código comentado es malo porque cuando otras personas leen el código, especialmente cuando estás estresado tratando de corregir un error cuando el autor original está de vacaciones, es porque es muy confuso leer el código, especialmente si el error es desde una ubicación incorrecta // al comienzo de la línea ... incluso si usa / * puede comentar por accidente algo que debería haber estado allí, o no.

Para mantener su código limpio y más legible, elimine el código comentado, ya es difícil leer los programas tal como están sin tener que leer el código que puede o no ser significativo.

Sí, lo es.

Incluso si tiene un código de depuración que no desea en su versión de producción, no debe comentarlo. Usar #ifdef 's es mejor, porque entonces puede activar y desactivar la depuración fácilmente con una macro #define , o tener una configuración de compilación separada. Esto definitivamente supera el hecho de tener que ingresar el código y comentar / no comentar todos los bloques del código de depuración manualmente.

Y si necesita tener flexibilidad para activar algunos bloques de depuración pero no otros, entonces debe agrupar los bloques de depuración en "niveles de depuración".

Una mejor solución sería no usar el preprocesador en absoluto, y usar características del idioma nativo, como constantes y sentencias if. Así que en lugar de

#define DEBUG0
#ifdef DEBUG0
  // debugging code
#endif

puedes tener

const bool DEBUG0 = true;
if(DEBUG0)
{
  // debugging code
}

La ventaja de hacer esto, sobre el uso del preprocesador, es que el compilador siempre verificará su código de depuración. Esto disminuye la probabilidad de que se pudra al cambiar el código que lo rodea.

No sufrirías ningún impacto en el rendimiento si hicieras que la bandera booleana fuera falsa, porque los compiladores modernos optimizan el código inalcanzable. En el peor de los casos, podría recibir una advertencia del compilador al respecto.

No creo que lo que estás haciendo esté mal, pero creo que al menos deberías tener algunos comentarios reales para explicar lo que está haciendo, por qué y cómo y cuándo usarlo.

Personalmente, normalmente pondría este tipo de cosas en algún tipo de esfuerzo IF DebugMode = TRUE alrededor del código en cuestión y lo configuré como un parámetro de inicio / línea de comando. Para mí, eso hace que sea más fácil ver que ese es el motivo por el que está el código y cómo configurarlo, aunque en su instancia puede haber problemas de rendimiento incluso con esa pequeña comparación que desea evitar.

Así que probablemente vería lo que estás haciendo como un mal necesario en lugar de salir mal. Si puedes encontrar la forma de simplificarlo, obviamente, hazlo, pero no me daría una paliza al respecto.

Creo que una de las razones por las que el código comentado se considera un olor de código es que indica que el programador que lo colocó allí no entiende su control de fuente o que no está usando ninguno. Cualquiera de los cuales arroja más dudas sobre muchas de las otras cosas que están haciendo también.

Si tiene una razón legítima para ello y deja una explicación de por qué es una razón legítima en la que se puede encontrar, probablemente esté bien. La mayoría de las cosas que generalmente se consideran malas noticias también pueden ser una herramienta útil en las manos adecuadas. El problema es que esas manos son más raras que las personas que piensan que las tienen.

Ayuda a proporcionar un historial de cómo funcionaban las mentes de los programadores en ese momento. Pero en estos días de control de fuente ubicuo no hay razón para dejarlo en un corte final: las versiones anteriores contendrán el código más antiguo en caso de que alguna vez necesites referirte a él.

No creo que haya absolutos aquí. A veces, dejo un código comentado cuando es solo un pequeño fragmento, especialmente si existe una posibilidad razonable de que lo descomente de nuevo pronto. Básicamente, dejo esos fragmentos de código siempre y cuando no interrumpan la legibilidad del código real, y siempre y cuando no se multipliquen en todas partes.

Lo que rechazo absolutamente es el método completo de código comentado. Sí, los he visto antes: WTF. Pueden descansar en la revisión de la fuente del cielo ;-)

Use el comentario si su programa será modificado por otras personas o si está modificando el trabajo de otras personas. No desea que otras personas eliminen su código y luego descubrió que su código era mejor. Además, si envía un programa modificado por usted, que fue escrito por otro, y luego el programa falla, es mejor que ore que solo haya comentado el código original de su colega para que pueda revertir el cambio. Estoy diciendo la situación cuando la empresa no usa un sistema de control de versiones.

También comenta su código si desea hacer referencia a su código más adelante, por ejemplo, está intentando un enfoque diferente para el mismo objetivo.

El comentario no afecta el rendimiento del lenguaje compilado o el lenguaje basado en máquinas virtuales.

Si uno encontró un comentario realmente molesto, puede usar un mejor IDE con función para ocultar algunos comentarios seleccionados.