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

Question

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

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

10

Un suggerimento del "Codice pulito" di Bob Martin mi fa grattarmi la testa ... "Se una volta la funzione chiama un altro, dovrebbero essere chiusi verticalmente e il chiamante dovrebbe trovarsi sopra il punto di chiamata"

Finora, sono stato più o meno vicino alle linee guida .Net, che raggruppano i membri della classe per tipo (proprietà, cori, funzioni) e visibilità (pubblico / privato / privato). All'inizio il suggerimento sembra un problema ... ma "potrebbe funzionare". Personalmente ho riscontrato casi in cui mi è piaciuto questo layout: è più facile eseguire il drill down quando si è nella giusta sequenza di chiamate.

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

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

}

code-formatting

posta Gishu 08.06.2011 - 14:52

fonte

3 risposte

Leggi altre domande sui tag code-formatting

Algoritmo per generare tutti i gruppi di m punti in n x n x n reticolo cubico che sono unici sotto simmetria Mantenere una cronologia git pulita durante l'utilizzo di gitflow - commit non interrotti durante lo sviluppo

score 2 · Answer 1

Potrei uscire su un arto qui, ma mi chiedo se lo strumento che usi abbia 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 sorgente. In genere, è possibile ottenere un elenco dei metodi ordinati alfabeticamente, per visibilità o anche per restituire il testo in una barra laterale. Puoi anche saltare a un metodo se ne hai l'uso. Puoi anche generare alberi di chiamata per i metodi e approfondire. In genere hai anche un comando di ricerca potente che potrebbe supportare espressioni regolari. In questa situazione, l'ordine dei metodi che crei non ha importanza in quanto hai visualizzazioni diverse dal codice sorgente disponibile.

In un editor di testo, in genere non possiedi queste funzionalità: la cosa più vicina a te probabilmente è una strong scoperta / sostituzione. Qui, vorrai prestare maggiore attenzione alla struttura del tuo file poiché potrebbe essere più difficile da navigare. Desiderate ridurre al minimo il tempo trascorso scorrendo attorno al file per trovare ciò che state cercando e un ordine coerente e logico di metodi può aiutare.

score 1 · Answer 2

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

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

score 1 · Answer 3

Se per periodo prolungato intendi per più di un paio di giorni? Quindi No.
Un paio di anni fa ho iniziato a fare questo su un nuovo codice, e lentamente mi sono lasciato impazzire, fino a quando non mi sono fermato.

La mia preferenza personale per la definizione delle classi è

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

Ma non è religioso, le proprietà e i metodi possono essere mescolati insieme. La visibilità non vi entra (non raggruppo per pubblico / protetto / privato)

Abbiamo un ragazzo qui in ufficio che mantiene una struttura rigida su tutto in un file di classe, con tutto raggruppato in gruppi principali e sottogruppi, tutti ben annidati nelle regioni. . . Devo ammettere che penso che le regioni siano opera di Satana, mi guidano in giro per il giro.

Ogni volta che apro uno dei suoi corsi muoio un po 'dentro: (