Estándar de codificación Java/mejores prácticas: convención de nomenclatura para etiquetas de pausa/continuación

Question

A veces, una pausa o una continuación etiquetadas pueden hacer que el código sea mucho más legible.

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break OUTERLOOP;
    //...more code
}

Me preguntaba cuál era la convención común para las etiquetas.¿Todas las mayúsculas?primera gorra?

Answer 1

Si tiene que usarlos, use mayúsculas, esto llama la atención sobre ellos y evita que se interpreten erróneamente como nombres de "Clase".Llamar la atención sobre ellos tiene el beneficio adicional de captar la atención de alguien que vendrá, refactorizará su código y los eliminará.;)

Answer 2

No entiendo de dónde viene esta regla de "no usar etiquetas".Cuando se realiza una lógica de bucle no trivial, la prueba para interrumpir o continuar no siempre está claramente al final del bloque circundante.

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

Sí, casos como este ocurren todo el tiempo.¿Qué me sugiere la gente que use en su lugar?¿Una condición booleana como esta?

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

¡Qué asco! Refactorizarlo como método tampoco alivia eso:

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

Seguro que es un poco más bonito, pero sigue pasando un booleano superfluo.Y si el bucle interno modificó las variables locales, refactorizarlo en un método no siempre es la solución correcta.

Entonces, ¿por qué estáis todos en contra de las etiquetas?Dame algunas razones sólidas y alternativas prácticas para el caso anterior.

Answer 3

La convención es evitar las etiquetas por completo.

Hay muy, muy pocas razones válidas para utilizar una etiqueta para salir de un bucle.Romper está bien, pero puedes eliminar la necesidad de romperlo modificando un poco tu diseño.En el ejemplo que ha dado, extraería las secciones "Mucho código" y las colocaría en métodos individuales con nombres significativos.

for ( ;/*stuff*/; ) 
{
    lotsOfCode();

    if ( !isEnough() )
    {
        moreCode();
    }
}

---

Editar: habiendo visto el código real en cuestión (aqui), creo que el uso de etiquetas es probablemente la mejor manera de hacer que el código sea legible.En la mayoría de los casos, usar etiquetas es un enfoque incorrecto; en este caso, creo que está bien.

Answer 4

El estilo de código Java de Sun parece preferir nombrar etiquetas de la misma manera que las variables, es decir, mayúsculas y minúsculas con la primera letra en minúscula.

Answer 5

La convención que más he visto es simplemente caso de camello, como el nombre de un método...

myLabel:

pero también he visto etiquetas con el prefijo de guión bajo

_myLabel:

o con laboratorio...

labSomething:

Sin embargo, probablemente puedas sentir por las otras respuestas que te resultará difícil encontrar un estándar de codificación que diga algo más que "No usar etiquetas".Entonces supongo que la respuesta es que debes usar cualquier estilo que tenga sentido para ti, siempre que sea consistente.

Answer 6

wrt ejemplo de código de sadie:

Diste

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

Como ejemplo.Haces un buen punto.Mi mejor suposición sería:

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

Pero habrá ejemplos en los que ese tipo de refactorización no encaja correctamente con cualquier lógica que esté haciendo.

Answer 7

Como las etiquetas rara vez son útiles, parece que no existe una convención clara.La especificación del lenguaje Java tiene un ejemplo con etiquetas y están en non_cap.

Pero como son tan raros, en mi opinión lo mejor es pensar dos veces si realmente son la herramienta adecuada.

Y si son la herramienta adecuada, póngalas en mayúsculas para que otros desarrolladores (o usted mismo más adelante) se den cuenta de que son algo inusual de inmediato.(como ya señaló Craig)

Answer 8

La convención/mejor práctica seguiría siendo no usarlos en absoluto y refactorizar el código para que sea más legible usando extraer como método.

Answer 9

Son una especie de recurso de Java; no estoy seguro de si C# los tiene.Nunca los he usado en la práctica, no se me ocurre ningún caso en el que evitarlos no resulte en un código mucho más legible.

Pero si es necesario, creo que todo en mayúsculas está bien.La mayoría de las personas no utilizan pausas etiquetadas, por lo que cuando ven el código, las mayúsculas les saltan a la vista y les obligan a darse cuenta de lo que está pasando.

Answer 10

Lo sé, no debería usar etiquetas.

Pero supongamos que tengo un código que podría ganar mucho en legibilidad a partir de saltos etiquetados, ¿cómo los formateo?

Mo, tu premisa es incorrecta.La pregunta no debería ser "¿cómo les doy formato?"

Su pregunta debería ser "Tengo un código que tiene una gran cantidad de lógica dentro de los bucles. ¿Cómo puedo hacerlo más legible?"

La respuesta a esa pregunta es mover el código a funciones individuales y bien nombradas.Entonces no es necesario etiquetar los descansos en absoluto.