In Java, gli helper privati dovrebbero andare al di sopra o al di sotto dei metodi pubblici? [chiuso]

Anche se normalmente si tratta di preferenza, dovresti cercare di aderire a uno standard comune all'interno della tua organizzazione. Quindi qualunque cosa tu decida, scegli uno standard e adottalo universalmente.

Per quanto riguarda la scelta, se dovessi seguire i suggerimenti offerti in Pulisci codice , potresti leggere il file dall'alto verso il basso come un articolo di giornale, che suggerirebbe naturalmente che i metodi di supporto appaiano dopo i metodi che stanno aiutando. Ciò porterebbe alla massima leggibilità della struttura del codice. Quindi se dovessi avere

public void doSomething()
{
     helpMe();
     helpMeAgain();
}

Il tuo file sarebbe strutturato come

public void doSomething() { }
private void helpMe() { }
private void helpMeAgain() { }

Un altro effetto collaterale di questo è che scopri che i tuoi aiutanti hanno i loro aiutanti e ti aiuta a capire che cosa hai realmente un'altra classe che vive nel tuo file, e puoi chiaramente rifattorizzare per estrarla nella sua classe dal questi metodi sono già raggruppati in ordine. Ma questo è un beneficio secondario.

I metodi pubblici sono l'interfaccia della classe. Qualcuno interessato a usare la tua classe si preoccuperà solo dell'interfaccia. Dal punto di vista di un utente di classe, sarebbe utile avere prima i metodi pubblici per ridurre lo scorrimento.

In C e C ++, i metodi di supporto vengono spesso inseriti per primi perché non è necessaria una dichiarazione. Molte persone hanno portato questa abitudine in altre lingue dove non ha importanza.

Preferisco i metodi pubblici in cima perché di solito quando apro un file cerco la sua interfaccia pubblica. Non voglio dover scorrere oltre tutti i dettagli di implementazione. Capita anche di essere lo stile più popolare che abbia mai visto, quindi c'è da dire per convenzione.

Mi piace che l'ordine dei metodi in una classe sia basato sulla leggibilità e sul contesto, non sulla visibilità.

vale a dire. un metodo "aperto" probabilmente appartiene prima di una "chiusura". Se due metodi pubblici 'a' e 'b' chiamano una 'c' privata, e sono gli unici a chiamarla - allora mi piace 'c' essere accanto a loro.

Non credo che una convenzione sull'ordinamento dei metodi basata sulla visibilità sia una buona cosa.

Preferisco preferire le mie lezioni in cui i membri sono elencati in ordine di importanza / visibilità (qui per importanza intendo che hanno un impatto diretto sull'interfaccia pubblica).

Quindi le funzioni private tendono a essere respinte.

Ci sono delle eccezioni a questo in cui tenderemo anche a raggruppare insieme le funzionalità simili, quindi è ancora possibile trovare piccole funzioni private che si mescolano con le cose pubbliche.

Questa è, come hai detto, una questione di gusti.

Tuttavia, quando si lavora su un codice che non è mio, proverò a seguire le convenzioni utilizzate nel progetto.

Un modo carino che ho trovato per tenere traccia di ciò è (supponendo che lavori con Eclipse) creare una configurazione di formattazione del codice ed esportarla con l'origine del progetto e assegnarla al controllo del codice sorgente. In questo modo, l'ultima e più grande convenzione in codice per il progetto è a soli pochi clic di distanza per l'impostazione e l'attivazione di CTRL-SHIFT-F prima del commit impedirà un sacco di argomenti.

Il bonus aggiuntivo sull'utilizzo di formattatori automatici è che puoi fare le cose in qualsiasi convenzione che ti renda felice e basta formattare il codice prima del commit. YMMV in base a detta convenzione e strumento di formattazione.