O problema com o Code Folding

Quando o senhor entra em uma equipe, é importante flexibilizar um pouco suas preferências para acomodar as práticas de codificação geralmente aceitas por essa equipe. É claro que nem todos precisam concordar com cada detalhe minúsculo do código, mas é uma boa ideia discutir o assunto com sua equipe e decidir antecipadamente sobre abordagens e filosofia gerais. Isso promove a harmonia da equipe e, mais do que isso, é apenas uma cortesia comum. Como se costuma dizer, quando em Roma, faça como os romanos.

Sempre desconfiei de codificadores cowboys que entram em um projeto em andamento com cavalos frescos e imediatamente começam a ditar os termos. De fato, é uma viagem muito curta de lá para cá. Quem escreveu essa porcaria?e começa o previsível e inevitável apontar o dedo para os programadores imprudentes que vieram antes do senhor. Não seja esse senhor ou senhora. Trabalhe com sua equipe, e não contra ela.

Ainda assim, existem algumas preferências de codificação que as pessoas podem sentir… fortemente… sobre. Se esse for o caso, tente esclarecer as coisas e abordar essas preferências fortes logo de início, o mais cedo possível. Não deixe que elas se acalmem. Para mim, o uso de #region é uma dessas coisas. Tentei ser claro em esta mensagem no Twitter:

Então, o que é #region? É uma dica nomeada que o senhor coloca no código C# ou VB.NET para definir um ponto de dobragem de código. Qualquer código colocado dentro dessa região é, por padrão, recolhido quando o senhor o reabre no editor. Aqui está um exemplo aleatório do Projeto Log4Net:

Imediatamente, tenho um problema: Não consigo ver nada! Tenho que expandir manualmente essas seções para navegar em qualquer código dessa classe. É possível configurar o IDE do Visual Studio para não dobrar nenhuma das regiões quando os arquivos são abertos, mas esse é o comportamento padrão, portanto, é o que a maioria dos desenvolvedores verá. E, é claro, há atalhos de teclado para lidar com as regiões:

Aqui está a parte realmente doentia: quando o senhor expande o código log4net acima, há literalmente três páginas de código lá! Depois de remover todos os comentários XMLDoc enormes e as dezenas de diretivas #region, o senhor poderia ter tido todo o código na ponta dos dedos com um pequeno movimento da roda do mouse, em um layout simples e rolável.

Atrevo-me a dizer que ser capaz de ver o maldito código é mais importante do que tê-lo meticulosamente segmentado em seis pequenos compartimentos nomeados sem sentido, mas aparentemente muitos programadores não se cansam de colocar seu código em pequenos compartimentos nomeados sem sentido. É como se eles tivessem esquecido o que é a barra de rolagem e o que é o pesquisa incremental — é para.

O #region me deixa louco. Ela não é má, por si só, mas acho que é criminosamente usada em excesso na prática e muito propensa a abusos. Recomendo enfaticamente que o senhor reflita sobre como está usando o code folding, pois, a meu ver, há muitas desvantagens:

1. As diretivas de dobramento são comentários glorificados. #region não tem significado algum para o compilador; é uma dica para o editor permitir o dobramento de código. Ele não faz nenhum namespacing ou scoping. Por que, exatamente, estamos escrevendo código para acomodar o editor? Não consigo imaginar que adicionaríamos linhas significativas de código ao nosso projeto que não fazem nada além de oferecer dicas organizacionais ao editor. Até mesmo os comentários tradicionais valem mais o seu pressionamento de tecla, pois podem ser mais expressivos. E a dobragem certamente não substitui a refatoração de fato.
2. Folding é usado para varrer o código para debaixo do tapete. O senhor tem um monte de código boilerplate chato que lhe dá água nos olhos? Um monte de código feio e malfeito que ninguém em sã consciência quer ver? Esconda-o em uma região e dobre-o até o esquecimento! Problema resolvido, certo? Não é bem assim. Seu projeto agora está cheio de código de baixa qualidade que o senhor não consegue ver. Isso é pior. Muito pior! O código que se esconde do senhor é um código que apodrecerá da forma mais putrescente e dolorosa possível. Seu código deve estar sempre na frente e no centro, exposto ao maior número possível de olhos de programadores e à maior quantidade possível de luz curativa.
3. A dobra é usada para mascarar o comprimento excessivo. A presença de código dobrado pode fazer com que os desenvolvedores tenham uma falsa sensação de que o código é limpo. Sob o disfarce da dobra, o senhor pode acabar escrevendo blocos de código espaguete longos e horríveis. Se o código precisar da muleta da dobragem para veja organizado, é um código ruim.
4. O dobramento pode ocultar deficiências em seu editor. A presença das chamadas regiões “padrão”, como “Construtores públicos”, “Propriedades públicas” e “Eventos”, não é um recurso. É um bug. O editor deve automaticamente se oferecem para dobrar esses blocos estruturais comuns para o senhor! Fico sempre surpreso com o fato de os programadores gastarem tempo fazendo esse trabalho de rotina quando poderiam estar escrevendo códigos úteis. Ou, pelo menos, exigindo um editor de código mais inteligente.

Peço aos desenvolvedores que escrevam códigos que não necessidade que a dobragem seja legível, clara e concisa. Tenho certeza de que há usos sensatos para a dobragem de código em algum lugar, mas raramente os vejo.