en Visual (al menos como lo hacia) creaba los formularios y asignaba los eventos sin pensar como debería estar estructurado un error mio como programador !
Lo que realmente deberías considerar es no llenar todo el Form (me refiero la clase "Form1" que hereda del tipo Form) de métodos, variables y demás "porquería" que no tenga nada que ver con los eventos del Form, me refiero, en la clase "Form1" (o como se llame la clase) solo deberías escribir los controladores de eventos del Form y eso ya sería más que suficiente, el resto de la lógica deberías considerar separarlo de la clase del Form y, aparte, los bloques de código de un controlador de eventos nunca debería ser largo, siempre puedes definir un método en otra class y llamarlo desde el controlador de eventos ocupando una sola linea de código.
(esto que te digo es en base a los consejos de las guías de diseño de Microsoft, no es una opinión personal, que también)
un error mio como programador !
No creo que se pueda considerar un error, no lo veas así, por que realmente ser desordenado al programar no supone nada grave (a menos que tengas intención de publicar una API, ahí si), solo es una mala costumbre que siempre puedes intentar mejorar.
Además existen excepciones donde para ser ordenados no queda más remedio que "apilar" bloques de código como tu dices, se que lo siguiente que voy a decir no interesa a nadie pero quiero darte un ejemplo, mira, yo tengo una API pública donde en una de las clases escribí más de 8.000 lineas de código, pero por necesidad, puesto que es una clase que recopila funciones Win32 de la dll
User32.dll de Windows, es decir, es una clase donde solo hay escritas definiciones de funciones de esa dll y en mi opinión no hay mejor manera de clasificarlo que en una única clase, por muchos miles de lineas de código que contenga, lo podría separar alfabeticamente en clases con nombres del estilo:
User32_A.vb...
User32_Z.vb -pero creo que eso más que ayudar a encontrar algo solo consigue hacerlo más dificil.
Saludos!