Na minha humilde opinião, geralmente é algo a ser evitado em grande parte pelo código de produção, porque geralmente você não é tentado a fazê-lo, exceto em funções esporádicas que executam tarefas díspares. Costumo fazê-lo em algum código de sucata usado para testar as coisas, mas não sinto tentação de fazê-lo no código de produção, onde pensei antes sobre o que cada função deve fazer, pois a função naturalmente terá uma escopo limitado em relação ao seu estado local.
Eu realmente nunca vi exemplos de blocos anônimos sendo usados assim (sem envolver condicionais, um trybloco para uma transação, etc.) para reduzir o escopo de maneira significativa em uma função que não implorava a pergunta de por que não podia ser dividido ainda mais em funções mais simples, com escopos reduzidos, se realmente se beneficiasse praticamente do ponto de vista genuíno do SE dos blocos anônimos. Geralmente, o código eclético está fazendo um monte de coisas pouco relacionadas ou muito relacionadas, nas quais estamos mais tentados a buscar isso.
Como exemplo, se você estiver tentando fazer isso para reutilizar uma variável denominada count, isso sugere que você está contando duas coisas díspares. Se o nome da variável for tão curto quanto count, então faz sentido associá-lo ao contexto da função, que poderia estar contando apenas um tipo de coisa. Em seguida, você pode olhar instantaneamente o nome e / ou a documentação da função, ver counte saber instantaneamente o que isso significa no contexto do que a função está fazendo sem analisar todo o código. Não costumo encontrar um bom argumento para uma função contar duas coisas diferentes, reutilizando o mesmo nome de variável de maneira a tornar escopos / blocos anônimos tão atraentes em comparação com as alternativas. Isso não sugere que todas as funções contem apenas uma coisa. EU'benefício de engenharia para uma função reutilizando o mesmo nome de variável para contar duas ou mais coisas e usando blocos anônimos para limitar o escopo de cada contagem individual. Se a função é simples e clara, não é o fim do mundo ter duas variáveis de contagem com nomes diferentes, sendo que a primeira possui possivelmente mais linhas de visibilidade do escopo do que o ideal. Tais funções geralmente não são a fonte de erros que carecem de blocos anônimos para reduzir ainda mais o escopo mínimo de suas variáveis locais.
Não é uma sugestão para métodos supérfluos
Isso não é para sugerir que você crie métodos à força, apenas para reduzir o escopo. É indiscutivelmente tão ruim ou pior, e o que estou sugerindo não deve exigir uma necessidade de métodos "auxiliares" particulares, mais do que uma necessidade de escopos anônimos. Isso é pensar demais no código como está agora e como reduzir o escopo das variáveis do que pensar em como resolver conceitualmente o problema no nível da interface, de maneira que produza uma visibilidade curta e limpa dos estados da função local naturalmente sem aninhamento profundo de blocos e 6+ níveis de indentação. Concordo com Bruno que você pode dificultar a legibilidade do código colocando três linhas de código em uma função, mas isso começa com a suposição de que você está evoluindo as funções criadas com base na implementação existente, em vez de projetar as funções sem se envolver nas implementações. Se você fizer isso da última maneira, eu encontrei pouca necessidade de blocos anônimos que não servem para nada além de reduzir o escopo da variável em um determinado método, a menos que você esteja tentando zelosamente reduzir o escopo de uma variável em apenas algumas linhas de código inofensivo onde a introdução exótica desses blocos anônimos indiscutivelmente contribui com a sobrecarga intelectual que eles removem.
Tentando reduzir ainda mais os escopos mínimos
Se a redução de escopos de variáveis locais para o mínimo absoluto valeu a pena, deve haver uma ampla aceitação de código como este:
ImageIO.write(new Robot("borg").createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize())), "png", new File(Db.getUserId(User.handle()).toString()));
... como isso causa a visibilidade mínima do estado, nem mesmo criando variáveis para se referir a elas em primeiro lugar. Eu não quero parecer dogmático, mas acho que a solução pragmática é evitar bloqueios anônimos quando possível, assim como evitar a linha monstruosa de código acima e se eles parecem absolutamente necessários em um contexto de produção do perspectiva de correção e manutenção de invariantes dentro de uma função, definitivamente penso em como você organiza seu código em funções e cria suas interfaces vale a pena reexaminar. Naturalmente, se seu método tiver 400 linhas e o escopo de uma variável for visível para 300 linhas de código a mais do que o necessário, isso pode ser um problema de engenharia genuíno, mas não é necessariamente um problema a ser resolvido com blocos anônimos.
Se nada mais, a utilização de blocos anônimos em todo o lugar é exótica, não idiomática, e o código exótico corre o risco de ser odiado por outras pessoas, se não por você, anos depois.
A utilidade prática de reduzir o escopo
A utilidade final de reduzir o escopo das variáveis é permitir que você obtenha o gerenciamento de estado correto e mantenha-o correto, além de raciocinar facilmente sobre o que qualquer parte de uma base de código faz - para poder manter invariantes conceituais. Se o gerenciamento de estado local de uma única função é tão complexo que você precisa reduzir vigorosamente o escopo com um bloco anônimo de código que não deve ser finalizado e bom, novamente, isso é um sinal para mim de que a própria função precisa ser reexaminada . Se você tiver dificuldade em raciocinar sobre o gerenciamento de estado das variáveis em um escopo de função local, imagine a dificuldade de raciocinar sobre as variáveis privadas acessíveis a todos os métodos de uma classe inteira. Não podemos usar blocos anônimos para reduzir sua visibilidade. Para mim, ajuda começar com a aceitação de que as variáveis tenderão a ter um escopo um pouco mais amplo do que o ideal, em muitos idiomas, desde que não fique fora de controle a ponto de você ter dificuldade em manter invariantes. Não é algo para resolver tanto com bloqueios anônimos, como eu o vejo como aceitável do ponto de vista pragmático.