java - mostrar - private jlabel

¿Debo evitar el uso de Java Label Statements?

Question

Hoy tuve un compañero de trabajo que sugirió refactorizar mi código para usar una declaración de etiqueta para controlar el flujo a través de 2 bucles anidados que había creado. Nunca los he usado antes porque personalmente creo que disminuyen la legibilidad de un programa. Estoy dispuesto a cambiar de opinión sobre su uso si el argumento es lo suficientemente sólido sin embargo. ¿Cuáles son las opiniones de las personas sobre las declaraciones de etiqueta?

Answer 1

Creo que con el nuevo bucle for-each, la etiqueta puede ser muy clara.

Por ejemplo:

sentence: for(Sentence sentence: paragraph) {
  for(String word: sentence) {
    // do something
    if(isDone()) {
      continue sentence;
    }
  }
}

Creo que se ve muy claro al tener su etiqueta igual a su variable en el nuevo for-each. De hecho, tal vez Java debería ser malo y agregar etiquetas implícitas para cada una de las variables

Answer 2

Encontré que las etiquetas a veces son útiles en las pruebas, para separar la configuración habitual, el ejercicio y verificar las fases y las declaraciones relacionadas con el grupo. Por ejemplo, usando la terminología BDD:

@Test
public void should_Clear_Cached_Element() throws Exception {
    given: {
        elementStream = defaultStream();
        elementStream.readElement();
        Assume.assumeNotNull(elementStream.lastRead());
    }
    when:
        elementStream.clearLast();
    then:
        assertThat(elementStream.lastRead()).isEmpty();
}

Las opciones de formato pueden variar, pero la idea principal es que las etiquetas, en este caso, proporcionen una distinción notable entre las secciones lógicas que componen la prueba, mejor que los comentarios. Creo que la biblioteca de Spock se basa en esta característica para declarar sus fases de prueba.

Answer 3

Hay pocas ocasiones en que necesita etiquetas y pueden ser confusas porque rara vez se usan. Sin embargo, si necesita usar uno, utilice uno.

Por cierto: esto se compila y se ejecuta.

class MyFirstJavaProg {  
        public static void main(String args[]) {
           http://www.javacoffeebreak.com/java101/java101.html
           System.out.println("Hello World!");
        }
}

Answer 4

He utilizado un bucle etiquetado Java para una implementación de un método Sieve para encontrar números primos (hecho para uno de los problemas matemáticos de Euler del proyecto) que lo hizo 10 veces más rápido en comparación con los bucles anidados. Por ejemplo, si (cierta condición) vuelve al ciclo externo.

private static void testByFactoring() {
    primes: for (int ctr = 0; ctr < m_toFactor.length; ctr++) {
        int toTest = m_toFactor[ctr];
        for (int ctr2 = 0; ctr2 < m_divisors.length; ctr2++) {
            // max (int) Math.sqrt(m_numberToTest) + 1 iterations
            if (toTest != m_divisors[ctr2]
                        && toTest % m_divisors[ctr2] == 0) {
                continue primes; 
            }
        } // end of the divisor loop
    } // end of primes loop
} // method

Le pregunté a un programador de C ++ qué tan malos son los bucles etiquetados, dijo que los usaría con moderación, pero de vez en cuando pueden ser útiles. Por ejemplo, si tiene 3 bucles anidados y para ciertas condiciones desea volver al bucle más externo.

Entonces tienen sus usos, depende del problema que estabas tratando de resolver.

Answer 5

Las etiquetas son como las de Goto: úsenlas con moderación, y solo cuando hagan que su código sea más rápido y más importante, más comprensible,

Por ejemplo, si se encuentra en grandes bucles de seis niveles de profundidad y se encuentra con una condición que hace que el resto del ciclo no tenga sentido, no tiene sentido tener 6 trampas adicionales en las declaraciones de condición para salir temprano del ciclo.

Las etiquetas (y las de Goto) no son malvadas, es solo que a veces las personas las usan de malas maneras. La mayoría de las veces estamos tratando de escribir nuestro código, por lo que es comprensible para usted y para el próximo programador que se presente. Hacerlo súper rápido es una preocupación secundaria (tenga cuidado con la optimización prematura).

Cuando Labels (y goto''s) son mal utilizados, hacen que el código sea menos legible, lo que causa dolor para usted y para el próximo desarrollador. Al compilador no le importa

Answer 6

Muchos algoritmos se expresan más fácilmente si se puede saltar a través de dos bucles (o un bucle que contiene una declaración de cambio). No te sientas mal por eso Por otro lado, puede indicar una solución demasiado compleja. Así que retroceden y miren el problema.

Algunas personas prefieren un enfoque de "entrada única, salida única" para todos los bucles. Es decir, evitar el break (y continuar) y el retorno anticipado para los bucles. Esto puede dar como resultado un código duplicado.

Lo que evitaría fuertemente es introducir variables auxiliares. Ocultar el flujo de control dentro del estado aumenta la confusión.

La división de los bucles etiquetados en dos métodos puede ser difícil. Las excepciones son probablemente demasiado pesadas. Pruebe un enfoque de entrada única y salida única.

Answer 7

Nunca he visto etiquetas usadas "en la naturaleza" en código Java. Si realmente desea dividir los bucles anidados, vea si puede refactorizar su método para que una declaración de devoluciones anticipadas haga lo que desee.

Técnicamente, creo que no hay mucha diferencia entre un regreso anticipado y una etiqueta. Prácticamente, sin embargo, casi todos los desarrolladores de Java han visto un retorno temprano y saben lo que hace. Supongo que muchos desarrolladores al menos se sorprenderían con una etiqueta, y probablemente estarían confundidos.

Me enseñaron la ortodoxia de entrada única / salida única en la escuela, pero desde entonces he llegado a apreciar declaraciones de retorno temprano y ruptura de bucles como una forma de simplificar el código y hacerlo más claro.

Answer 8

Nunca uso etiquetas en mi código. Prefiero crear un protector e inicializarlo a nulo u otro valor inusual. Este guardia es a menudo un objeto de resultado. No he visto a ninguno de mis compañeros de trabajo usar etiquetas, ni encontré ninguno en nuestro repositorio. Realmente depende de tu estilo de codificación. En mi opinión, el uso de etiquetas disminuiría la legibilidad, ya que no es una construcción común y, por lo general, no se usa en Java.

Answer 9

Sí, debe evitar usar etiquetas a menos que haya una razón específica para usarlas (el ejemplo de simplificar la implementación de un algoritmo es pertinente). En tal caso, aconsejaría que añada suficientes comentarios u otra documentación para explicar el razonamiento que lo respalda, de modo que alguien no venga más tarde y lo desarregle con la noción de "mejorar el código" o "deshacerse del código malicioso" o alguna otra excusa potencialmente BS.

Yo igualaría este tipo de pregunta con la decisión de cuándo se debería o no usar el ternario si. La principal razón es que puede impedir la legibilidad y, a menos que el programador tenga mucho cuidado de nombrar las cosas de una manera razonable, entonces el uso de convenciones como las etiquetas puede empeorar las cosas. Supongamos que el ejemplo que usa ''nextCondition'' y ''nextItem'' ha usado ''loop1'' y ''loop2'' para los nombres de sus etiquetas.

Personalmente, las etiquetas son una de esas características que no tienen mucho sentido para mí, aparte de Assembly o BASIC y otros lenguajes igualmente limitados. Java tiene muchas construcciones de bucle y control más convencionales / regulares.

Answer 10

Tengo curiosidad por saber cuál es tu alternativa a las etiquetas. Creo que esto va a reducirse al argumento de "regresar tan pronto como sea posible" frente a "usar una variable para mantener el valor de retorno, y solo regresar al final".

Las etiquetas son bastante estándar cuando tiene bucles anidados. La única forma en que realmente disminuyen la legibilidad es cuando otro desarrollador nunca los ha visto antes y no entiende lo que significan.

Answer 11

Yo discutiría a favor de ellos en algunos lugares, los encontré particularmente útiles en este ejemplo:

nextItem: for(CartItem item : user.getCart()) {

  nextCondition : for(PurchaseCondition cond : item.getConditions()) {
     if(!cond.check())
        continue nextItem;
     else
        continue nextCondition;

  }
  purchasedItems.add(item);
}