Formattazione del codice: disporre le funzioni in base alla gerarchia delle chiamate all'interno di un file di classe?

Un suggerimento del "Clean code" di Bob Martin mi fa grattare la testa. "Se una volta una funzione chiama un'altra, dovrebbero essere vicini verticalmente e il chiamante dovrebbe essere al di sopra della chiamata"

Finora, sono stato più o meno fedele alle linee guida .Net, che raggruppano i membri della classe per tipo (proprietà, informazioni, funzioni) e visibilità (pubblico / prot. / Privato). All'inizio la punta sembra un problema ... ma "potrebbe funzionare". Personalmente ho riscontrato casi in cui mi è piaciuto questo layout, più facile da analizzare quando sei nella giusta catena di chiamate.

L'idea alla base del suggerimento sembra valida ma altri scenari come "fammi guardare l'interfaccia pubblica di questa classe" potrebbero peggiorare. Forse lo zio Bob punta sulle piccole classi e sul supporto IDE per la visualizzazione dei tipi ...

Qualcuno l'ha provato per un lungo periodo?

Aggiornamento: sembra che uno snippet di codice sia in ordine

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... }

}

Potrei uscire su un arto qui, ma mi chiedo se lo strumento che usi ha un impatto su questo. Mi riferisco all'editor di testo rispetto alla decisione IDE che gli sviluppatori devono prendere.

In un IDE, hai molte più funzionalità per visualizzare i file di origine. In genere, è possibile ottenere un elenco dei metodi ordinati alfabeticamente, in base alla visibilità o addirittura restituire il tipo in una barra laterale. Puoi anche saltare a un metodo se ne hai un uso. È inoltre possibile generare alberi delle chiamate per i metodi ed eseguire il drill down. In genere hai anche un potente comando find che potrebbe supportare espressioni regolari. In questa situazione, l'ordine dei metodi che crei davvero non ha importanza poiché hai viste diverse dal codice sorgente disponibile.

In un editor di testo, in genere non si dispone di queste funzionalità: il più vicino che si avrà è probabilmente una forte ricerca / sostituzione. Qui, vorrai prestare maggiore attenzione alla struttura del tuo file poiché potrebbe essere più difficile navigare. Si desidera ridurre al minimo il tempo trascorso a scorrere il file per trovare ciò che si sta cercando e può essere d'aiuto un ordine coerente e logico dei metodi.

Il punto è che le cose chiamate sono meno interessanti delle cose chiamate. Più un metodo chiama altri metodi, più è probabile che quel metodo faccia parte dell'API esterna dell'oggetto (anziché essere un dettaglio di implementazione). Ciò significa che l'API esterna della classe - metodi pubblici, se la tua lingua supporta tale concetto - naturalmente "vorrà" trovarsi in cima al file, rendendo più facile trovare quei metodi. Al contrario, le funzioni di supporto e tali "vorranno" essere nella parte inferiore del file.

(Sto spiegando il concetto, non sto valutando la sua efficacia.)

Se per periodo prolungato intendi per più di un paio di giorni? Quindi no.
Un paio di anni fa ho iniziato a farlo con un nuovo codice e lentamente mi sono impazzito, fino a quando non mi sono fermato.

La mia preferenza personale per l'organizzazione di lezioni è

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

Ma non è religioso, proprietà e metodi possono mescolarsi insieme. La visibilità non entra (non raggruppo per pubblico / protetto / privato)

Abbiamo un ragazzo qui in ufficio che mantiene una struttura rigorosa su tutto in un file di classe, con tutto raggruppato in gruppi principali e sottogruppi, tutti ben nidificati nelle regioni. . . Devo ammettere che penso che le regioni siano opera di Satana, mi guidano attorno al colpo di scena.

Ogni volta che apro una delle sue lezioni muoio un po 'dentro :(