En mi humilde opinión, generalmente es algo que debe evitarse en gran medida para el código de producción porque generalmente no está tentado a hacerlo, excepto en funciones esporádicas que realizan tareas dispares. Tiendo a hacerlo en algún código de desecho utilizado para probar cosas, pero no encuentro la tentación de hacerlo en el código de producción, donde he pensado con anticipación qué debe hacer cada función, ya que, naturalmente, la función tendrá alcance limitado con respecto a su estado local.
Nunca he visto ejemplos de bloques anónimos que se usen de esta manera (sin involucrar condicionales, un trybloque para una transacción, etc.) para reducir el alcance de una manera significativa en una función que no plantea la pregunta de por qué no pudo se dividirá aún más en funciones más simples con alcances reducidos si realmente se benefició prácticamente desde un punto de vista de SE genuino desde los bloques anónimos. Por lo general, es un código ecléctico que está haciendo un montón de cosas poco relacionadas o muy poco relacionadas donde estamos más tentados a alcanzar esto.
Como ejemplo, si está tratando de hacer esto para reutilizar una variable llamada count, entonces sugiere que está contando dos cosas dispares. Si el nombre de la variable será tan corto como countpara mí, entonces tiene sentido vincularlo con el contexto de la función, que podría estar contando un tipo de cosa. Luego puede ver instantáneamente el nombre y / o la documentación de la función, ver county saber instantáneamente lo que significa en el contexto de lo que está haciendo la función sin analizar todo el código. A menudo no encuentro un buen argumento para que una función cuente dos cosas diferentes reutilizando el mismo nombre de variable de manera que los ámbitos / bloques anónimos sean tan atractivos en comparación con las alternativas. Eso no sugiere que todas las funciones tengan que contar solo una cosa. YO'beneficio de ingeniería para una función que reutiliza el mismo nombre de variable para contar dos o más cosas y usa bloques anónimos para limitar el alcance de cada recuento individual. Si la función es simple y clara, no es el fin del mundo tener dos variables de conteo con nombres diferentes, y la primera posiblemente tenga algunas líneas más de visibilidad de alcance de lo que idealmente se requiere. Dichas funciones generalmente no son la fuente de errores que carecen de tales bloques anónimos para reducir aún más el alcance mínimo de sus variables locales.
No es una sugerencia para métodos superfluos
Esto no es para sugerirle que cree métodos con fuerza, ya sea solo para reducir el alcance. Podría decirse que es igual de malo o peor, y lo que sugiero no debería exigir la necesidad de métodos "auxiliares" privados incómodos más que la necesidad de ámbitos anónimos. Eso es pensar demasiado en el código tal como está ahora y cómo reducir el alcance de las variables que pensar en cómo resolver conceptualmente el problema a nivel de la interfaz de manera que produzca una visibilidad limpia y corta de los estados de la función local de forma natural sin una anidación profunda de bloques y más de 6 niveles de sangría. Estoy de acuerdo con Bruno en que puede obstaculizar la legibilidad del código insertando con fuerza 3 líneas de código en una función, pero eso comienza con el supuesto de que está desarrollando las funciones que crea en función de su implementación existente, en lugar de diseñar las funciones sin enredarse en implementaciones. Si lo hace de esta manera, he encontrado poca necesidad de bloques anónimos que no sirvan para nada más allá de reducir el alcance de la variable dentro de un método dado, a menos que esté tratando celosamente de reducir el alcance de una variable con solo unas pocas líneas menos de código inofensivo donde la introducción exótica de estos bloques anónimos posiblemente contribuya con la sobrecarga intelectual que eliminan.
Tratando de reducir los alcances mínimos aún más
Si valía la pena reducir los ámbitos de variables locales al mínimo absoluto, entonces debería haber una amplia aceptación de código como este:
ImageIO.write(new Robot("borg").createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize())), "png", new File(Db.getUserId(User.handle()).toString()));
... ya que eso causa la visibilidad mínima del estado al ni siquiera crear variables para referirse a ellas en primer lugar. No quiero parecer dogmático, pero en realidad creo que la solución pragmática es evitar los bloques anónimos cuando sea posible, así como evitar la monstruosa línea de código anterior, y si parecen tan absolutamente necesarios en un contexto de producción del perspectiva de la corrección y el mantenimiento de invariantes dentro de una función, entonces definitivamente creo que vale la pena volver a examinar cómo está organizando su código en funciones y diseñando sus interfaces. Naturalmente, si su método tiene 400 líneas de largo y el alcance de una variable es visible para 300 líneas de código más de lo necesario, eso podría ser un verdadero problema de ingeniería, pero no es necesariamente un problema para resolver con bloques anónimos.
Por lo menos, el uso de bloques anónimos en todo el lugar es exótico, no idiomático, y el código exótico conlleva el riesgo de ser odiado por otros, si no por usted mismo, años después.
La utilidad práctica de reducir el alcance
La utilidad final de reducir el alcance de las variables es permitirle obtener la administración de estado correcta y mantenerla correcta y permitirle razonar fácilmente sobre lo que hace cualquier parte de una base de código, para poder mantener invariantes conceptuales. Si la administración de estado local de una sola función es tan compleja que tiene que reducir a la fuerza el alcance con un bloque anónimo en el código que no está destinado a ser finalizado y bueno, nuevamente, eso es una señal para mí de que la función en sí misma necesita ser reexaminada . Si tiene dificultades para razonar sobre el manejo del estado de las variables en un ámbito de función local, imagine la dificultad de razonar sobre las variables privadas accesibles para cada método de una clase completa. No podemos usar bloques anónimos para reducir su visibilidad. Para mí, ayuda comenzar con la aceptación de que las variables tenderán a tener un alcance ligeramente más amplio de lo que idealmente necesitan tener en muchos idiomas, siempre que no se salga de control hasta el punto en que tenga dificultades para mantener invariantes. No es algo para resolver tanto con bloques anónimos como lo veo como aceptar desde un punto de vista pragmático.