Também ouvi dizer que se você não consegue ver um método inteiro de uma vez no seu editor, é hora de refatorá-lo.
A coisa mais básica a fazer neste caso é usar “cláusulas de guarda”, ou o que é frequentemente chamado de inversão. Código profundamente aninhado geralmente acontece porque há muitos códigos aninhados if declarações. Mas se você inverter o if declaração para “sair se as coisas não estiverem certas” em vez do padrão “continue perguntando se você pode continuar”, você pode evitar muitas das situações booleanas que entopem o cérebro. Muitas vezes, a inversão pode realmente remover todos os níveis de aninhamento em um método.
A outra estratégia é sempre extrair código para métodos menores, para que nenhum bloco de código fique muito grande. Desenvolvedores seniores não têm medo de muitas classes e métodos pequenos. E, claro, todas essas classes serão nomeadas descritivamente, certo?
Desenvolvedores seniores não comentam seu código
Deixei este para o final porque sei que muitos desenvolvedores ficam irritados com essa noção. Eu sou, no entanto, bastante inflexível nesse ponto. Acredito firmemente que 99,9% dos comentários são uma indicação de código ruim, nomenclatura ruim ou falta de variáveis explicativas. Se você sente a necessidade de comentar seu código, é quase certo que é porque seu código não é claro e facilmente compreendido. Se seu código não é claro e facilmente compreendido, então ele precisa ser reescrito até que seja. (Nomear bem e usar variáveis explicativas ajudará.)
Além disso, os comentários não são fisicamente vinculados ao código ao qual se referem e podem ficar perdidos, causando muita confusão.
