¿Cuál es la mejor práctica para marcar las variables que necesita eliminar más adelante en Java?

Question

Me rasqué la cabeza durante dos semanas tratando de calcular algo basado en una variable.

Resulta que establecí la variable más temprano para resolver temporalmente otro problema y nunca volví a corregirlo.

Normalmente, trato de marcar el código con // ToDo para recordarme que elimine la variable temporal.

En este caso, no lo marqué porque estaba salteando intentando arreglar más de unas pocas cosas. (No pude entender qué estaba pasando, ¡así que estaba probando todo tipo de cosas!)

¿Cómo marca las variables temporales que desea eliminar más adelante?

1. ¿Los instancias como privados en la parte superior de la clase?
2. Márquelos en línea con algo como // Eliminar Me Later

Lo que es es la mejor práctica para el marcado de variables que es necesario eliminar más adelante?

(corto de tener un cerebro muy organizada, por supuesto ...)

Answer 1

En lugar de hacer comentarios a todas las ideas/recomendación, pensé que iba a responder y luego tener que votar sobre esta respuesta.

Primero, muchas gracias por compartir sus procesos e ideas. Realmente lo aprecio.

Creo que hay una serie de factores en juego que deben ser impulsados ​​por el deseo de evitar cometer errores estúpidos o sufrir de los que ya ha cometido. Hice uno (de muchos.)

Supongamos que el control de versiones y las opiniones del equipo prevalecen sobre todas; Sin embargo más allá del control de versiones (suponiendo que usted cometió crappola a su buen código):

• @Deprecated es muy bueno. Parece fulminarte. Todos necesitamos deslumbrar. Con suerte, podemos ver el bosque a través de los árboles.

• Para mí, los diffs son onerosos ya que con frecuencia hago cambios radicales, pero es una gran sugerencia que funciona en muchos casos.

Algunas cosas notables:

Puesto que soy por lo general único desarrollador, que dependen de todos. Son fáciles de usar Tengo un sistema informal de calificación con todos. Por ejemplo, algo que realmente tiene que ser limpiado se ve así:

//TODO * Might be a future crash here // where one star is something I really have to clean up before I ship. 
//TODO *** Can some lines be trimmed from this view adapter? 

múltiples estrellas son arbitrarias y tal vez incluso opcional. Sigo yendo en bicicleta a través de ellos. @ BriGuy37 - ese fue un pensamiento interesante. @Sriram - eso también fue interesante - estableciendo etiquetas bajo ciertas condiciones.

En mi caso, no hice dox el // TODO y me quemó.

más grande imperio tal vez por todo esto es:

unificar su trabajo de una manera que usted no hace errores estúpidos como este. Sepa qué cambios está haciendo y cuándo. Mantenga la calma.

¡Gracias nuevamente! ¡Es genial recoger las mejores prácticas de la comunidad para incorporarlas a tu trabajo!

Answer 2

encontramos después de un poco de google, ya que era curioso también.

@Deprecated 
public void speak() { 
    System.out.println("Meow."); 
} 

De Wikipedia, en Java annotations:

Java define un conjunto de anotaciones que se construyen en el idioma . Anotaciones aplicadas al código java: @Override - Comprueba que la función es una anulación. Causa una advertencia de compilación si la función no se encuentra en una de las clases principales. @Deprecated - Marca la función como obsoleta. Provoca una advertencia de compilación si se utiliza la función . @SuppressWarnings - Indica al compilador suprimir las advertencias de tiempo de compilación especificadas en la anotación parámetros Anotaciones aplicadas a otras anotaciones: @Retention - Especifica cómo se almacena la anotación marcada - Ya sea en código solo, compilada en la clase o disponible en tiempo de ejecución a través de la reflexión. @Documented: marca otra anotación para incluirla en la documentación de . @Target: marca otra anotación para restringir qué tipo de elementos Java de la anotación se puede aplicar a @Inherited - Marca otra anotación para heredar a las subclases de la clase anotada (de manera predeterminada, las anotaciones no se heredan a las subclases).

Answer 3

Utilice la anotación @Deprecated

@Deprecated 
public void Test() { 
    // 
} 

Answer 4

La mejor práctica es utilizar el control de versiones. Una vez que haya solucionado un error, puede git/hg/svn diff para verificar lo que ha hecho desde la última confirmación y eliminar los cambios temporales. Si necesita corregir otros errores, pero mantiene el "cambio temporal" en varias confirmaciones, puede hacer confirmaciones parciales (git add --patch, o hg qrecord) para que sus "cambios temporales" nunca se comprometan y se olviden.Para temporarios muy grandes (no es una práctica recomendada, pero puede suceder), puede crear una rama local que continúe reajustando sobre el código normal. Una vez que esté seguro de eliminar los "cambios temporales", simplemente puede limpiar los cambios no confirmados y luego probar los problemas.

Answer 5

Sucursales locales (git, shelving cambia en IntelliJ, dos copias de la fuente comprobadas localmente), de modo que cuando se mueve de una tarea a otra, en lugar de simplemente trabajar sobre el trabajo completado en parte, crea un segunda rama y no comprometer/presionar la primera hasta que se haya completado.

Compromisos/empujes de par - por lo que no se compromete hasta que haya hablado el código con una segunda persona, que apuntará al fragmento temporal de código y le preguntará al respecto. Ojalá te obligue a solucionar el maldito problema antes de cometerlo.

No use TODO ni otros comentarios como nunca se realizarán acciones en ellos.

Si ya es público y se está utilizando externamente, @Deprecate it.

Answer 6

En primer lugar, prefijo cada nombre de variable con "TODO_REMOVE_" o algo similar. De esta forma, si me olvido de eliminarlo y alguien lo encuentra más tarde, está claro que la variable debe eliminarse. Además, si realizo el último paso a continuación, SIEMPRE lo eliminaré antes de registrarlo.

A continuación, agregue un comentario HACERLO y anotarlo con Obsoleto. Sé que otros han dicho que TODOs nunca son accionados, pero cuando hago un commit, mi IDE (IntelliJ en este caso) me advierte que hay X TODOs comprometidos. Si recibe un mensaje similar cuando se registra, eso debería arrojar una bandera en su mente. Además, si te encuentras haciendo esto a menudo, crea una plantilla en vivo, un fragmento o cualquier otra cosa que tu IDE ofrezca para que solo tengas que escribir el tipo de clase y el nombre de la variable.

@Deprecated 
Object TODO_REMOVE_variableName;//TODO Remove 

pasado, tratan de volver a leer, comprender, mejorar y confirmar cada línea de código que escribo antes de comprobar un cambio establecido. Esto es crucial! Sé que puede sonar desalentador al principio, especialmente para grandes cambios o cuando se acerca la fecha límite, pero es una gota en el cubo al lado del tiempo que tardó en escribir el código, y los problemas que revela y el tiempo futuro guarda bien vale la pena. En verdad, me gustaría que cada desarrollador hiciera esto.

Answer 7

Si está utilizando Eclipse, me gustaría que sugeriría

tener una nueva etiqueta de tarea, digamos, 'eliminar', lo que podría ayudar a identificar fácilmente lo que necesita ser eliminado código temporal. Establezca la prioridad en Alto.

Abra la vista de tareas para verificar la eliminación de tareas y tomar medidas.

Por favor, pasar por debajo de enlace (una captura de pantalla de interfaz de usuario se proporciona también)

StackOverflow Q/A on Task tags

Answer 8

Si está utilizando SVN * y el cambio que está realizando es algo que debe solucionarse antes de que se realicen los cambios (por ejemplo, un cambio temporal para la depuración/prueba local) puede agregar un comentario como // STOP-COMMIT y configurar un enlace precompromiso que prohíbe la asignación de cualquier archivo que contenga este texto.

Esto también funciona bien para marcar los cambios locales en los archivos de configuración que no deben comprometerse con SVN.

Si su IDE admite una lista de TODO que buscar comentarios para una cadena dada, incluso puede crear un formato TODO personalizado buscando esta cadena.

* yo supongo que puede hacer algo similar con muchos otros sistemas de control de versiones