Formateo de código: ¿Presentar funciones basadas en la jerarquía de llamadas dentro de un archivo de clase?

Una sugerencia del "Código limpio" de Bob Martin me hace rascarme la cabeza ... "Si una función llama a otra, deben estar verticalmente cerca y la persona que llama debe estar por encima de la persona que llama"

Hasta ahora, me he mantenido más o menos cerca de las pautas .Net, que agrupan a los miembros de la clase por tipo (propiedades, factores, funciones) y visibilidad (público / prot. / Privado). La sugerencia parece un problema al principio ... pero "podría funcionar". Personalmente, he encontrado casos en los que me gustó este diseño, más fácil de profundizar cuando estás en la cadena de llamadas correcta.

La idea detrás de la sugerencia parece sólida, pero otros escenarios como "déjame mirar la interfaz pública de esta clase" podrían empeorar. Tal vez el tío Bob está confiando en las clases pequeñas y el soporte IDE para ver los tipos ...

¿Alguien ha probado esto durante un período prolongado?

Actualización: Parece que un fragmento de código está en orden

class SomeType()
{
  /// fields, ctors, et. all
  public void Method1()   { // calls HelperMethod1 and HelperMethod2 }
  private void HelperMethod1 { // calls HelperMethod3 }
  private void HelperMethod3 {}
  private void HelperMethod2 {}

  public void Method2 () { // and so on... }

}

Puede que me esté arriesgando aquí, pero me pregunto si la herramienta que usa tiene un impacto en esto. Me refiero al editor de texto versus la decisión IDE que los desarrolladores deben tomar.

En un IDE, tiene mucha más funcionalidad para ver los archivos de origen. Por lo general, puede obtener una lista de los métodos ordenados alfabéticamente, por visibilidad o incluso tipo de retorno en una barra lateral. También puede saltar a un método si tiene un uso para él. También puede generar árboles de llamadas para métodos y profundizar. Por lo general, también tiene un poderoso comando de búsqueda que puede admitir expresiones regulares. En esta situación, el orden de los métodos que cree realmente no importa, ya que tiene vistas distintas al código fuente disponible.

En un editor de texto, generalmente no tiene estas características: lo más cercano que tendrá es probablemente una búsqueda / reemplazo fuerte. Aquí, querrá prestar más atención a la estructura de su archivo, ya que puede ser más difícil de navegar. Desea minimizar el tiempo dedicado a desplazarse por el archivo para encontrar lo que está buscando, y un orden coherente y lógico de métodos puede ayudar.

El punto es que las cosas llamadas son menos interesantes que las cosas llamadas. Cuanto más un método llama a otros métodos, más probable es que ese método sea parte de la API externa del objeto (en lugar de ser un detalle de implementación). Eso significa que la API externa de la clase (métodos públicos, si su idioma admite ese concepto) naturalmente "querrá" estar en la parte superior del archivo, lo que facilitará la búsqueda de esos métodos. Por el contrario, las funciones de ayuda y tal "querrán" estar al final del archivo.

(Estoy explicando el concepto, no evaluando su efectividad).

¿Si por período extendido te refieres a más de un par de días? Entonces No.
Hace un par de años comencé a hacer esto con un código nuevo, y lentamente me volví loco, hasta que paré.

Mi preferencia personal para diseñar clases es

class MyClass
{
    // static fields
    // fields
    // constructors
    // properties
    // methods
} 

Pero eso no es religioso, las propiedades y los métodos pueden mezclarse. La visibilidad no entra en él (no lo agrupo por público / protegido / privado)

Tenemos un tipo aquí en la oficina que mantiene una estructura estricta sobre todo en un archivo de clase, con todo agrupado en grupos principales y subgrupos, todos muy bien anidados en regiones. . . Tengo que admitir que creo que las regiones son obra de Satanás, me llevan a dar la vuelta.

Cada vez que abro una de sus clases me muero un poco por dentro :(