¿Debo eliminar el código no referenciado?

La mayoría de las razones para mantenerlo son absolutamente irrelevantes, en pocas palabras. Si no se usa el código, deséchelo, cualquier beneficio involucrado en mantenerlo puede derivarse de manera trivial del control de código fuente. A lo sumo, deje un comentario que indique en qué revisión encontrarlo.

Sencillamente, cuanto antes corte el código, antes no tendrá que perder tiempo manteniéndolo, compilándolo y probándolo. Esas ventajas superan enormemente los beneficios triviales que ha descrito, todos los cuales pueden derivarse del control de origen de todos modos.

Todas las razones para eliminarlo son válidas.

Razones para conservarlo:

• Se puede utilizar como referencia
• Puede ser útil en algún momento
• Es posible que se haya escrito para "redondear" la funcionalidad de una clase.

Todas estas razones para mantenerlo serán administradas por el control de fuente. Elimínelo del código en vivo y podrá recuperarlo cuando sea necesario.

El código no referenciado es lo mismo que mantener esas baterías que son un poco planas, en caso de que las necesite un día para una antorcha.

Siempre y cuando estés usando algún tipo de control de versión, diría que eliminarlo del código activo y usar el historial de versiones en caso de que resulte útil.

La única buena razón que puedo ver para conservar el código que no se usa actualmente es si es parte de un módulo independiente: si bien es posible que algunas partes del código no se usen en este momento, puede ser que se utilizarán en el futuro.

Esto puede ser especialmente cierto para una biblioteca que usa en diferentes proyectos: no desea seguir lanzando fragmentos de código dentro y fuera, de acuerdo con lo que necesita para un proyecto específico: me parece que esto consume mucho tiempo y error. propenso.

Mi enfoque es: (1) si lo usa una vez, solo mantenga lo que realmente necesita; (2) si lo usa dos veces, cópielo y adáptelo la segunda vez que lo use; (3) si lo usa más de dos veces, cree un módulo estable y bien definido y use este módulo según lo necesite.

Resumen: Desecharía todo el código no utilizado a menos que sea parte de un módulo de propósito general que usted haya diseñado como tal y que sepa que lo va a reutilizar varias veces.

Nota : por supuesto, una solución aún más limpia sería crear un proyecto separado para una biblioteca y agregar una dependencia entre proyectos.

En general, me inclino ante YAGNI por esto. Si "no lo va a necesitar", entonces simplemente está ocupando espacio en su base de código, pruebas unitarias y ensamblajes. Puede terminar necesitándolo, pero también puede necesitar reescribirlo completamente porque entre ahora y cuando necesite algo así, muchas cosas pueden cambiar.

Sin embargo, eso cambia un poco cuando escribes una utilidad o API destinada al consumo general. Al igual que nunca puede esperar que los usuarios finales del software interactúen con el software de la manera que usted quería, nunca puede esperar que los consumidores de su código quieran usar su código exactamente de la manera que usted cree que deberían. En tales casos, siempre que pueda justificar la existencia de un método con "es una forma válida de querer interactuar con mi objeto", entonces probablemente debería entrar, porque incluso si no lo va a necesitar, es probable que ALGUIEN .

Dado que el código base tiene menos de un año de antigüedad, es probable que todavía fluya mucho (¿sí?), por lo que la idea de que algunos bits deben resucitarse en un futuro próximo no es irrazonable.

Para los bits que fueron difíciles de corregir en primer lugar y que parecen más resucitados, los mantendría un poco más "vivos" que solo en el control de código fuente. La gente no sabrá / recordará que existe; decir "puedes encontrarlo en el control de la fuente" ¡se supone que sabes / recuerda que está ahí! En este tipo de casos, considere la desaprobación (con un showstopper "assert (false)") o comente.

Si el código es trivial y poco interesante, simplemente lo desecho para eliminar la inercia innecesaria del sistema de software.

Para cadáveres de código interesantes, uso una rama archive en mis sistemas de control de versiones.

Una buena razón para mantener los métodos no utilizados es: ¡podrían usarse en otras ramas / etiquetas!

Explore todas sus ramas y etiquetas activas antes de eliminarlas.

Si usa un sistema de control de versiones, no se preocupe por referencias futuras, ya que simplemente puede ver a través del historial de ese código y encontrar la parte eliminada. Si no lo hace y cree que se usará algún día, simplemente deje que permanezca allí, pero coméntelo con una descripción que explique por qué está comentado.

Sin embargo, si está seguro de que no lo usará en el futuro, simplemente elimínelo . Creo que las razones que ha mencionado son bastante sencillas para eliminar el código.

Pero antes de retirarlo, asegúrese de que no se use en ningún lugar. Visual Studio tiene una función llamada Buscar todas las referencias que busca en toda la solución y encuentra cualquier referencia a la variable actual, método, propiedad, clase, interfaz, etc. Siempre me aseguro de que no haya ninguna referencia. antes de eliminar parte de mi código.

Es relativamente frecuente que haya tenido la experiencia de encontrar una función que parece que hará exactamente lo que necesito, y confío en que funcione, ya que ha estado en producción durante mucho tiempo, solo para descubrir que no ha funcionado. Se ha utilizado en varios años. El código que no se usa no se mantiene, y si bien pudo haber funcionado hace años, la API ha cambiado lo suficiente como para que no puedas confiar en él.

En el mejor de los casos, terminas gastando mucho tiempo asegurándote de que realmente haga lo que quieres. En el peor de los casos, parece funcionar hasta que te muerde con un error desagradable más tarde, y demora en rastrearlo porque asumiste que el código "probado en producción" funciona, por lo que el problema debe estar en otra parte en tu nuevo código. En mi experiencia, casi siempre es más rápido escribir una nueva función yo mismo.

Si lo elimina, pero descubre que lo necesita relativamente pronto, está justo ahí en el control de código fuente. Si no lo necesitas hasta que haya pasado tanto tiempo que no recuerdes que está en control de código fuente, es mejor que lo escribas desde cero.

Nada consume menos tiempo que ningún código.

Si tiene que sumergirse en una base de código, necesita algo de tiempo para averiguar para qué se usa ese código y, si se usa para nada, necesita aún más tiempo.

Bien, esto podría curarse como un comentario, pero nuevamente, todos razonarán acerca de por qué este código no utilizado todavía está en la base del código, ya sea que se deba eliminar o no.

Si no hay nada, nadie perderá tiempo con él.

Si fue difícil hacerlo bien, necesita una buena documentación, que este código existe, pero si el código base evoluciona en algunas iteraciones, tal vez ya no funcione, si se reactiva.

Elimine el código no utilizado: menos desorden, mejor comprensión. Tu sistema de control de versiones se hará cargo. Además, si está usando algo mejor que el bloc de notas, su entorno le permitirá usar código antiguo como referencia.

Los comentarios largos del código antiguo distraen y dificultan la navegación.

Saludos

Siga este algoritmo simple:

1. ¿Está respaldado en un SCM? Si es así, salta a 3.
2. Configurar un SCM.
3. Deshazte de las cosas .

Todos sus puntos a favor de la eliminación son válidos.

Todos sus puntos a favor de mantener el desorden no son válidos una vez que tenga un SCM para buscarlo o restaurarlo. En realidad, su SCM debería poder ayudarlo a determinar por qué ese código está aquí y no se utiliza, si se usó correctamente.

Se llama "código muerto" por una razón. Déjalo morir y descansa en paz.

"Puede usarse como referencia" No tiendo a estar de acuerdo con ser una buena razón para dejar el código sin usar. A menudo, solo una pequeña parte del código no utilizado en realidad está demostrando algo interesante. Hay varias formas de documentar y almacenar código útil pero no utilizado.

Aunque el control de versión contendrá un historial que le permitirá restaurar funcionalidades particulares si más tarde decide que se necesita el código, sabiendo que debe buscar en el historial de control de versiones para encontrar xy o z de quién sabe qué. La revisión puede ser un poco tediosa, y a menudo se pasa por alto a menos que tenga una idea bastante específica de lo que está buscando.

El código se puede comentar con una nota sobre cuándo se eliminó y por qué no se eliminó simplemente del código. Sin embargo, esto generalmente se considera un estilo malo, y el código que no se usa y no se mantiene correctamente puede introducir todo tipo de errores si no se comenta más adelante, por lo que generalmente es mejor como un paso de prueba / depuración temporal mientras que la refactorización media es mayor que Una forma de dejar el código de producción.

Mi forma favorita de almacenar el código eliminado, si parece ser útil en el futuro, es hacer un documento de referencia secundario que contenga todos los diversos fragmentos de código eliminado que valga la pena. Cada bloque de código está etiquetado con una breve mención de dónde provino o cualquier otra cosa pertinente para recordar, como cuándo se eliminó o el número de revisión en el que estaba el código. Todo lo que se elimina, pero "potencialmente útil" está en un solo lugar, es fácil de buscar, pero no requiere un esfuerzo constante para mantenerlo y realizar pruebas de forma continua (las pruebas se remiten a cualquier punto en el que se vuelva a introducir el código).

Se mantendrá en el control de la fuente; no debe permanecer en la base de código activa.

La única excepción es si el código completa el diseño y si no lo estás utilizando, planeas hacer el código público y otros pueden querer esa funcionalidad básica. Luego, solo diseñe pruebas para asegurarse de que estas partes del código funcionen de manera similar a la forma en que usted propone que otras personas puedan usar estas partes del código. Sin embargo, si está considerando eliminar el código y no puede encontrar una razón sólida para conservarlo, debería irse. El código no utilizado hace más trabajo para todos (es más difícil leer el código; es posible que se rompa el código; más trabajo que mantener, etc.)

En mi experiencia, la eliminación del código no utilizado también puede ser contraproducente. Puede olvidar que tenía ese código y no lo buscará en la historia. O tal vez ni siquiera sepa que alguien había implementado ese código y luego lo eliminó más tarde. De nuevo, no lo buscarás en la historia ...

Sin duda, tener un código no utilizado es un mal olor.

ACTUALIZACIÓN: Me di cuenta de que Ed Staub dio una respuesta muy similar.