Formattazione multilinea di firme / chiamate a funzioni lunghe [chiusa]

Question

Formattazione multilinea di firme / chiamate a funzioni lunghe [chiusa]

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

-2

Supponiamo che tu abbia una firma come questa:

public void MyFooBar(IExtraSuperLongTypeName param1, TypeA param2 ISomeotherReallyLongTypeName param3, TypeB param4, TypeC param5)

La formattazione su una riga è brutta e difficile da leggere. Uno stile utilizzato da resharper per formattare questo è per spingere i parametri in basso così

public void MyFooBar(IExtraSuperLongTypeName param1, TypeA param2,
    ISomeotherReallyLongTypeName param3, TypeB param4, TypeC param5)

Ma trovo ancora difficile interpretare immediatamente i parametri.

Ho anche visto questo approccio usato:

public void MyFooBar(IExtraSuperLongTypeName param1,
                     TypeA param2,
                     ISomeotherReallyLongTypeName param3,
                     TypeB param4,
                     TypeC param5)

Trovo che questo sia molto più facile da leggere, ma non sono un fan di avere tutto quello spazio bianco sulla strada, e non mi piace come la spaziatura degli spazi bianchi potrebbe non corrispondere esattamente alle dimensioni della scheda. Inoltre, se il nome del metodo è troppo lungo, può comunque spingere i parametri troppo a destra.

Ho pensato ad un altro modo per formattare il codice in questo modo:

public void MyFooBar
(
    IExtraSuperLongTypeName param1,
    TypeA param2,
    ISomeotherReallyLongTypeName param3,
    TypeB param4,
    TypeC param5
)

Per me, questo è facile da leggere e non soffre degli svantaggi dell'approccio di cui sopra. Qualcuno può vedere eventuali problemi con il metodo di formattazione di cui sopra? Se non riesco a trovare alcun motivo per non scrivere le funzioni in questo modo, inizierò a utilizzarlo nei miei progetti per le firme di metodo lunghe. Lo stesso approccio può essere fatto per funzionare chiamate, ad esempio:

MyFooBar myFooBar = MyFooBar
(
    arg1,
    arg2,
    arg3,
    arg4,
    arg5
);

coding-style code-formatting development-process programming-practices

posta eltommo 19.08.2016 - 08:13

fonte

4 risposte

Leggi altre domande sui tag coding-style code-formatting development-process programming-practices

Come gestire una riprogettazione dell'interfaccia utente completa di un prodotto Web? [chiuso] Previsione delle transazioni finanziarie

score 3 · Answer 1

Sono d'accordo che la tua formattazione sia facile da leggere e vedo solo due piccoli svantaggi:

Utilizza molto spazio (linee di codice)
Sembra un blocco di codice (se mischia le parentesi con parentesi graffe)

L'approccio migliore è nella maggior parte dei casi per evitare funzioni con molti argomenti. È possibile farlo, ad esempio inserendo variabili di argomento in una struttura o in un oggetto. Oppure puoi dividere la funzione in più funzioni più semplici.

score 0 · Answer 2

Può essere un odore di codice quando vengono aggiunti più di 3 parametri (non sono omogenei come x, y, z ); nel tempo sono stati aggiunti.

Crea una classe di parametri nella quale entra la maggior parte dei parametri. Guarda se le responsabilità sono separate e tali.

Il motivo è semplice: dopo 3 parametri la logica si ingarbuglia. Ora se è necessario modificare qualcosa nei parametri, la firma della funzione non cambierà più e potrebbero essere fornite impostazioni predefinite. Controlla se tali impostazioni predefinite sono già attive nei siti di chiamata.

Quindi come risposta alla domanda originale:

rimani con l'imballaggio di più su una riga.

Quando senti il prurito elencarli uno sotto l'altro, una classe parametro è imminente. Vai per intuizione.

In rari casi un tale metodo potrebbe diventare una sua classe.

score 0 · Answer 3

È uno stile di codifica . Ognuna di esse (esclusa la lenza singola) è accettabile e viene effettivamente utilizzata nei gruppi di programmazione reali. Ci sono pro e contro con ogni approccio dato che è più o meno un compromesso tra linee extra e autodocumentazione. E dato che l'autodocumentazione può esistere nei commenti appena sopra o sotto il codice se si usano le stringhe javadocs o python doc per esempio, nessuno degli approcci ha chiaramente sostituito gli altri.

Quindi ciò che conta nel mondo reale è solo la coerenza. Se i tuoi colleghi usano uno stile, fallo anche tu. E assicurati che venga utilizzato un singolo stile per ogni singolo progetto.

Sopra è principalmente per le dichiarazioni di funzione. Le chiamate di funzione multilinea vengono utilizzate raramente, poiché gli IDE aiutano automaticamente visualizzando i nomi dei parametri quando si digita e molti compilatori controllano la coerenza dei parametri.

score -1 · Answer 4

Il tuo metodo può essere usato, ma sono d'accordo con Frank che cerca di aggiungere argomenti correlati in una struct / class e lo usa come argomento della funzione. Oltre a questo, ti suggerisco di usare un commento sopra la descrizione di una funzione come in Android Studio (javadoc). In questo modo è molto più facile ottenere una breve conoscenza di ciò che fa la funzione, quali argomenti usa e il significato di ogni argomento proprio lì in un modo formattato corretto. Come

/* Function to do something
** @arg1 Length of list
** @arg2 Size of Square side
*/
int func (int arg1, int arg2) {
    // Do something
}