Metodi di ordinamento delle definizioni di funzioni nel codice

Al giorno d'oggi, con il supporto IDE per la navigazione delle tracce dello stack e la ricerca di chiamanti, trovo che non abbia importanza l'ordine dei miei metodi. C'è un leggero vantaggio nell'avere una piccola funzione di supporto vicino al luogo in cui è chiamato, in particolare quando viene chiamato solo in un posto, ma è molto più importante spezzare il modulo in piccole funzioni in primo luogo piuttosto che ordinarlo in modo ragionevole. Cercare di trovare l'arrangiamento "ottimale" quasi certamente non vale il tuo tempo (piuttosto costoso, spero). (Nota anche che le API generate automaticamente sono di solito ordinate alfabeticamente in ogni caso, quindi qualunque cosa tu faccia all'interno del tuo modulo non influisce nemmeno sugli altri.)

Preferisco la versione Clean Code. Se inizi a leggere una funzione, ogni nuova chiamata di funzione auto-implementata dovrebbe essere direttamente sotto di essa. Ad esempio in questo modo:

func Foo()
    func1()
    funcWithFuncs()
    func2

func func1()
    stuff

func funcWithFuncs()
    funcA()
    funcB()

func funcA()
    stuff

func funcB()
    stuff

func func2()
    stuff

In questo modo, puoi facilmente tracciare quale funzione è dove anche con funzioni che hanno più funzioni. Inoltre, non richiede uno stack di chiamate ed esegue il programma per trovare facilmente dove si trova tutto. Certo, questa è una cosa del "gusto", ma non ho ancora trovato Clean Code su questo punto.

Al contrario, lo odio quando le funzioni sono criptate perché non so quando smettere di scorrere; Potrei perderlo del tutto, cosa che accade più spesso di quanto vorrei con file di codice più grandi.

Forse è la forza dell'abitudine a codificare C più di 20 anni fa, ma, a prescindere dal linguaggio, di solito lascia che le mie piccole funzioni di supporto galleggiano verso l'alto.

Per lo meno, mi piacerebbe che ogni funzione fosse dichiarata prima di essere chiamata, al fine di ovviare alla necessità di prototipi forward di dichiarazione / funzione.

Suppongo che ciò mi renda esattamente l'opposto di @IAE (almeno 1 a lui ;-), anche se a volte rispecchia esattamente il suo approccio, avendo gli helper direttamente sopra la funzione che li chiama.

Se gli helper sono specifici per una funzione e il linguaggio consente le funzioni annidate, c'è molto da dire per annidare gli helper all'interno della funzione che li utilizza.

Preferisco l'approccio di refactoring iterativo. Mentre stiamo sviluppando l'applicazione di solito il nostro focus sarà sulle funzionalità. Una volta, c'è un codice che potremmo guardare e rifattarlo per renderlo più leggibile.

Per rispondere alla tua domanda sull'approccio (metodi per decidere dove posizionare un codice) - Poni le domande che ti verranno poste durante il refactoring per la nuova funzionalità o metodo che stai aggiungendo al codice.