Inserimento di argomenti sulle proprie linee [chiuso]

0

Questa domanda si applica a parametri e argomenti, poiché ho visto questo stile usato in entrambi.

Di solito scrivo parametri come questo

someFunction(arg0, arg1, arg2)

ma di recente ho notato che molte persone scrivono il loro in questo modo

someFunction(
arg0,
arg1,
arg2
) // the bracket doesn't have to be on its own line

Ho una domanda dalle molte sfaccettature qui:

1) È una pratica standard, una buona pratica o trascurabile mettere ogni argomento su una propria linea?
2) Sono le loro eccezioni a questo stile, come quando c'è un solo argomento?
3) Quali sono i pro e i contro di un tale progetto?

    
posta person27 02.02.2014 - 02:11
fonte

2 risposte

3

Come per qualsiasi altra domanda di formattazione del codice, è in gran parte una questione di opinione e di contesto.

Se si passa un numero limitato di parametri ei parametri sono variabili locali anziché il risultato di qualche altro metodo, avere tutto su una riga tende a rendere il codice più facile da leggere perché è adeguatamente compatto. Se, d'altra parte, stai passando un numero relativamente grande di parametri ed i parametri sono il risultato di chiamare altri metodi, le righe separate sono spesso migliori da un punto di vista della leggibilità perché non stai cercando di seguire dozzine di operazioni in un singolo linea di codice.

In altre parole, se ho qualcosa di simile

log( base => 2, exp => 8 )

è molto più facile da vedere su una singola riga. D'altra parte, se ho qualcosa di simile in cui sto istanziando un oggetto e passando un valore a un costruttore, chiamando un metodo su un altro oggetto, calcolando un valore da una variabile locale, passando in un'altra variabile locale e usando un costante, sarebbe molto difficile seguire una singola riga di codice. Avresti bisogno di più linee solo per poter vedere tutto a colpo d'occhio.

someBusinessFunction( new SomeObject( "file_name.txt" ),
                      anotherObject.GetListOfAddresses(),
                      aLocalVariable,
                      (case when someLocalVariable then 'Y' else 'N' end),
                      ASYNC_MODE );

Naturalmente, idealmente, probabilmente vorrai firme di metodo più semplici piuttosto che firme troppo complesse a parità di tutte le altre. Ma a volte i metodi hanno più senso quando accettano alcuni parametri. Potresti, naturalmente, anche creare più variabili intermedie su più righe di codice e quindi chiamare la funzione su una singola riga di codice. Questo può o non può semplificare la logica complessiva, però. Avresti ancora almeno tante linee di codice, ma ora avresti alcune variabili locali aggiuntive da tenere traccia di.

    
risposta data 02.02.2014 - 02:28
fonte
1

Esistono in realtà tre diversi modi per il layout di intestazione di routine ( Codice completo 2 ): nessun layout consapevole, layout di endline e indentazione standard. Il metodo preferito è il rientro standard

Layout non consapevole

I parametri sono disposti uno dopo l'altro, senza alcuna disposizione

bool ReadData(string employeeName, int employeeAge, int yearsOnJobMarket, bool isOperationSuccesful)

Queste routine sono viste come puramente utilitarie in quanto sia i computer che gli umani possono leggerle, ma causano problemi agli umani.

Layout di finezza

bool ReadData(string employeeName, 
              int    employeeAge, 
              int    yearsOnJobMarket, 
              bool   isOperationSuccesful)  

Questo approccio è pulito ed esteticamente attraente. Il problema principale è che ci vuole molto lavoro da mantenere, e questo di solito significa che non viene mantenuto. Ad esempio, se il nome della routine cambia in ReadNewData , il layout sarà simile a questo:

bool ReadNewData(string employeeName, 
              int    employeeAge, 
              int    yearsOnJobMarket, 
              bool   isOperationSuccesful) 

quindi ora devi cambiare manualmente il rientro di tutti gli altri parametri, o semplicemente dimenticarti e lasciarlo così com'è.

Indentazione standard

bool ReadData(
    string employeeName, 
    int employeeAge, 
    int yearsOnJobMarket, 
    bool isOperationSuccesful
)

Ora, in questo caso, non devi modificare nulla se il tuo nome di routine cambia o aggiungi / cancella nuovi parametri. Sembra buono per gli occhi, è leggibile e mantenibile.

Ancora una volta, queste non sono le mie idee, ma sono tratte da Codice completo 2 di Steve McConnell

    
risposta data 02.02.2014 - 07:24
fonte

Leggi altre domande sui tag