¿Es útil escribir código muerto?

¿Le resulta útil escribir código muerto?

Algunos dicen "Si tiene 2 lógicas para realizar alguna operación, en lugar de comentar otro código lógico o eliminar el código, hágalo como código muerto, ya que no afectará la operación".

Ejemplo:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

¿Es verdad?

Por lo general, no escribo códigos muertos sino que elimino la segunda lógica.

OMI, es peor que inútil.

Además de ser una pérdida de tiempo, te da a ti (o al siguiente tipo) la ilusión de que tienes un código que funcionará si cambias truea false. Es solo una ilusión ... a menos que lo pruebes.

Y, por supuesto, es el desorden lo que hace que el código sea más difícil de leer.

Si usa algún tipo de código muerto SCM, rara vez es útil. En su lugar, debe eliminarlo y si alguna vez necesita ver el código para la lógica 2, lo recuperará del repositorio de SCM.

Editar:

Si tiene un código inactivo y está manteniendo otras partes del código, puede intentar obtener usos de algún código que pueda activar el código inactivo. Si alguien más está haciendo el mantenimiento, es posible que no conozcan su código realmente muerto e incluso si lo hacen, seguramente no sabrán por qué todavía está allí.

Si luego cree que un método podría eliminarse, ya que no lo usa el código "en vivo" sino solo el código muerto, tendría que cambiar (y muy probablemente romper) su código muerto o hacer que el otro método sea el mismo código muerto.

Al final, seguramente terminarías en alguna forma de infierno de mantenimiento.

Por lo tanto, el mejor código es el código eliminado, ya que no puede producir resultados incorrectos ni distraer a los mantenedores. :)

No, eso es malo, porque satura tu código y reduce la capacidad de mantenimiento.

Por lo general, hay una razón clara para preferir una de las "lógicas" alternativas. Este motivo (y la existencia de una alternativa rechazada) debe documentarse en un comentario de código. En el caso relativamente improbable de que la razón se vuelva inválida, el código alternativo puede recuperarse del historial del repositorio (si era la solución implementada previamente preferida), o desarrollarse e implementarse utilizando el conocimiento y los requisitos actuales completos (si es solo un vago idea).

No afecta la operación pero sí afecta el mantenimiento. Desea mantener el código lo más ordenado posible para que sea más fácil de mantener.

Estoy sinceramente confundido por lo que estás haciendo.

En orden de prioridad descendente:

1. Debe mantener un registro de los cambios de código en algún lugar, de modo que si el nuevo código no funciona, puede compararlos. Esto siempre debe estar en control de fuente. Supongo que ya haces esto. Si no, haga todo lo posible para obtener ALGUNAS formas de control de código fuente. Si tiene que prescindir (y nunca en mi vida he oído hablar de una ocasión en que sea una buena idea), al menos haga copias de seguridad periódicas del estado de la fuente fácilmente accesibles.

2. Suponiendo que está haciendo el # 1, para que pueda recuperar el código muerto si lo necesita, NO lo mantenga en el código en vivo a largo plazo. Simplemente será confuso, agregará complejidad adicional sin valor, requerirá mantenimiento, no estará sincronizado con el código en vivo y engañará a las personas en el futuro, etc., etc.

3. Dicho esto, hay situaciones específicas en las que un cambio en tiempo de compilación entre dos rutas de código es razonable. Mientras desarrolla el nuevo código e inmediatamente después, puede ser conveniente tener ambos, por lo que puede cambiar fácilmente entre ellos. Si es probable que tenga que cambiar de nuevo o agregar una opción de configuración externa, un if basado en una constante le brinda a esos una ruta de actualización razonable. Entonces, como muchas cosas, si se trata de resolver un problema en particular, hazlo. Si no, evítalo.

La razón por la que supongo que los poemas lo hacen demasiado es: por tener dudas (a menudo correctamente) de que las personas realmente leerán el historial de control de la fuente si tienen un problema; de estar asustado, el nuevo código no funcionará y querer una opción de reversión fácil. Un compromiso para tratar de cumplir con ambos puede ser poner un comentario "Modificado para calcular ... el (Fecha). Si hay algún problema, vea la versión anterior en el control de origen" o similar.

No, no es útil. Ese elsebloque no cumple ningún propósito. Si no está seguro de qué implementación usar, coméntelo, haga clases separadas o guárdelo en otro lugar. Además, en su mayoría tiene, o al menos debería tener, un historial local o remoto de sus archivos fuente.

El compilador debe eliminar el código muerto si la condición depende de una constante de tiempo de compilación, por lo que técnicamente no estaría de más mantenerlo. Sin embargo, prefiero comentarlo, ya que esto mejora la legibilidad del código.

Si desea poder cambiar rápidamente entre dos alternativas de código, puede usar la siguiente construcción de comentarios conveniente:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

si elimina solo el primero /en la primera línea de comentario, se convierte en:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Con esto, puede cambiar entre las alternativas simplemente agregando o eliminando una sola /en el código.

Esto puede parecer un poco extraño al principio, pero una vez que te acostumbres, lo reconocerás fácilmente como algún tipo de patrón.

Incluso puede encadenar esto y así cambiar varios bloques a la vez con un solo carácter:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

No lo usaría de esta manera, pero funciona.

Hay algunas ocasiones muy raras en las que el código antiguo, y el hecho de que haya sido reemplazado, realmente debería permanecer en el código fuente para que los futuros programadores sean advertidos sobre algo que es contra-intuitivo. En cuyo caso, también es necesario algún tipo de comentario que explique por qué sigue ahí y qué sucedió.

Como siempre, escribir programas que sean fáciles de mantener se trata de aclarar las cosas, no solo de seguir reglas estrictas y rápidas. Si dejar el código muerto facilita la comprensión de lo que está sucediendo, déjelo. Si no, sáquelo.

Será ignorado por el compilador. Sin embargo, estoy de acuerdo con usted y simplemente eliminaría la declaración else. Suponiendo que esté utilizando el control de versiones, aún podrá ver el código antiguo al ver el historial del archivo.

Esta es probablemente una opinión personal, pero encuentro que el código muerto distrae al mantener un código. Para cualquier tarea, siempre tiene más de una forma de lograrla, por lo que debe elegir una. Investigue, evalúe los algoritmos y elija uno. Después de esto, el código no necesita contener ningún método alternativo dentro de él.

Si hay dos contendientes muy fuertes, escriba una pequeña nota sobre la alternativa y péguela en un wiki del proyecto o en otro lugar que contenga documentación del proyecto. Si lo desea, puede poner un comentario de una línea que haga referencia a este documento y describa por qué es posible que desee leerlo.

No puedo pensar de inmediato en una situación en la que encontré que escribir código muerto es útil. Si hay algoritmos alternativos, entonces:

• o mantienes el más útil y eliminas el otro,
• o los algoritmos son aplicables a diferentes circunstancias, y luego mantiene ambos y el condicional identifica las circunstancias cuando usa el primer algoritmo.

En cualquier caso, terminas sin código muerto.

Si no elimina o comenta su código muerto, deberá mantenerlo para evitar errores del compilador. Es tiempo perdido. Simplemente elimínelo si tiene un SCM.

NO

Algunos programadores usan este estilo como alternativa a los comentarios y lo encuentran elegante.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

La respuesta simple es un simple no. El código muerto atrae confusión y oportunidades para que ocurran errores. Tan pronto como escriba un carácter en el código, existe el riesgo. Así que no agregue más de lo necesario.

La única vez que tuve que escribir algo similar fue para solucionar un error del compilador, incluso el proveedor del compilador me recomendó que utilizara esta solución.

¿Pruebas el código muerto que escribes? ¿Hacer algo para confirmar que probablemente sea bueno? Si no, deshazte de él.

Para futuros cambios de código, ¿va a verificar que el código muerto todavía funciona? Si no, deshazte de él.

No desea un código incorrecto en sus programas, incluso si no se usa. Tenerlo allí sugiere que se puede usar. Por lo general, no desea mantener dos versiones de código si no usa ambas, porque es un trabajo adicional y, dado que se siente inútil, la mayoría de las personas no harán un buen trabajo con el código muerto.

Puede haber razones para mantener el código comentado (o, en C o C ++, #ifdefel código editado), pero esto debe ir acompañado de comentarios sobre por qué sigue ahí y para qué sirve.

Tenga en cuenta que en Java, lo siguiente ni siquiera se compilará, debido al código inalcanzable:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Idealmente, si hay algún problema con su código, desea encontrarlo lo antes posible, en lugar de dejarlo ir a producción y ser encontrado por sus usuarios.

Si su compilador puede encontrar una clase de error, deje que el compilador la encuentre. En mi humilde opinión, lo que alguien está haciendo escribiendo un código muerto de la manera que usted describe, está tratando de eludir ese error del compilador, permitiendo que surjan los problemas que pueda causar en tiempo de ejecución.

Puede argumentar que no se puede alcanzar el código muerto, por lo que no puede causar problemas, pero algo puede salir mal al comentar, apuntalar y sangrar que podría hacer que suceda.

La razón por la cual las personas comentan alguna lógica antigua es porque tienen miedo de hacer grandes cambios en el código. Y, de hecho, darse cuenta una semana después de que el código anterior era realmente correcto y que ahora tiene que escribirlo desde cero es una mierda. Pero para eso es el control de fuente. Si decide cambiar algo de lógica, no tenga miedo de perder el código actual que funciona. Elimínelo y deje que su SVN / Git / TFS se encargue del control de versiones por usted.

Si no es el caso y acaba de producir dos lógicas diferentes para hacer algo porque no le importa YAGNI o DRY, entonces asegúrese de ponerlo en un lugar donde la gente pueda usarlo. Tal vez lanzar un patrón de estrategia allí si lo desea. Simplemente no hagas estas cosas "si ... si no", es un mal diseño y un dolor de mantenimiento. Si realmente piensa que algún código tiene derecho a existir, asegúrese de que sea posible usarlo.

Otra mirada es que, básicamente, la mayoría de los programadores profesionales están de acuerdo en que el tamaño del código es el enemigo. Eche un vistazo a estas publicaciones de blog: el mejor código es ningún código de Jeff Atwood, el peor enemigo del código Steve Yegge, puede encontrar mucho más.

La gente está haciendo muchas cosas para mantener su código conciso y evitar que la base de código se vuelva demasiado grande, a menudo incluso sacrificando el rendimiento (donde no importa mucho). Entonces, ¿realmente crees que 100 líneas de código muerto pueden ser algo bueno?

El único lugar donde he visto que esto es útil es en los casos en que desea deshabilitar rápidamente algo y probar / rellenar (digamos que el programa realiza los pasos A, B, C, todo lleva mucho tiempo. Durante el relleno, puede optar por deshabilitar B y C por el momento para acelerarlo si sabes que no son necesarios).
Pero la verdad es que en todos los casos esto es muy hacky. Y si ve un uso a largo plazo para su código de relleno, debe escribir su código de tal manera que use config para elegir una opción en lugar de usar tales hacks.
Mi regla general es que nunca se registra este tipo de código. Si necesita un control de registro / versión, eso significa que podrá volver a esto pronto, y eso siempre es algo malo a la luz de los requisitos cambiantes.

En realidad, hay una forma en que es útil tener un código "inactivo": cuando desea que su programa arroje una gran excepción porque llegó a algo que nunca debería haber sucedido. Esto podría ser un error del compilador, o si alguien en la línea cambia la lógica en la prueba que está utilizando y lo arruina. De cualquier manera, su "otro" envía fuegos artificiales. En este caso, querrás ifdef para su lanzamiento.

Es de vital importancia que el mensaje de error indique algo como "Pánico: nunca se supone que estemos aquí en la línea% d en el archivo% s" ...