È una cattiva idea elencare ogni argomento di funzione / metodo su una nuova riga e perché?

Lavoro con qualcuno che, ogni volta che chiama una funzione, mette gli argomenti su una nuova riga, ad es

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

Lo trovo molto fastidioso in quanto significa che il codice non è molto compatto, quindi devo scansionare su e giù di più per dare un senso alla logica. Sono interessato a sapere se questa è in realtà una cattiva pratica e, in tal caso, come posso convincerli a non farlo?

È solo una linea guida per la codifica che potrebbe piacerti o meno. L'importante è che tu e i tuoi colleghi decidiate di usarlo o meno.

Ovviamente, il modo migliore per aumentare la leggibilità è limitare il numero di argomenti.

È una questione di preferenza. Per chiamate di funzioni complesse in cui si desidera documentare ciascun parametro o in cui le variabili sono piuttosto lunghe e ce ne sono molte, può essere utile.

Per esempio:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

Con le lingue che consentono i parametri denominati questo è più comune se si utilizzano i nomi dei parametri (l'esempio è in PL / SQL):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

Ma sono d'accordo con te sul fatto che se la chiamata di funzione è semplice e non ci sono troppi parametri, questo potrebbe diventare fastidioso, come:

setColour (
    r,
    g,
    b
 );

Trovo molto più facile da leggere come

 setColour(r,g,b);

Per @ammoQ:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

IMO tutto ciò che è insolito è una cattiva pratica a meno che non sia possibile dimostrare positivamente la superiorità rispetto al solito stile. "Matter of taste" è una scusa per scrivere codice che è più difficile da leggere del necessario per la maggior parte dei programmatori, perché un giorno un'anima povera, non abituata a quello stile, dovrà mantenere quel codice.

Dimostrare che non è comune è relativamente semplice, mostrare la fonte di esempi in MSDN o siti simili, mostrare basi di codice open source di grandi dimensioni, ecc. Mostrare l'output degli abbellitori di codice. Alla fine, mostra come lo sta facendo chiunque altro nella tua squadra. Non accettare uno stile cattivo solo perché qualcuno è troppo testardo.

Bene, ecco qualche esca negativa. Non sono mai stato accusato di fare la cosa popolare. Chiaramente, se le cose si adattano su una linea, allora bene, adattale su una linea.

Ma la mia preoccupazione principale non è se il codice sia "brutto" o "carino". La mia preoccupazione principale è quanto sia facile capire e apportare modifiche senza commettere errori.

Se gli argomenti sono lunghi e ce ne sono molti, perché non metterli su righe separate? A mio avviso, ciò rende più facile vedere cosa sono e più facilmente modificarli se necessario. Mi dà anche spazio per allegare un commento a ogni argomento, se lo desidero.

Voglio anche ridurre al minimo la possibilità di commettere un errore se aggiungo o rimuovo un argomento a una funzione, che è più probabile che accada alla fine di un elenco di argomenti rispetto all'inizio. Per questo motivo, preferisco mettere la virgola (,) all'inizio di una riga, piuttosto che alla fine. Quindi, se per esempio, desidero rimuovere o aggiungere un argomento alla fine dell'elenco, è una modifica di una riga. Non devo andare a giocherellare con la virgola che deve andare alla fine di tutte le righe ma all'ultima, dove l'ultima deve finire con una parentesi.

Quindi (ragazzo, mi infiammerò per questo) lo scrivo così:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

Quando c'è una funzione con da cinque a venti argomenti, la funzione non è stata così in una sola volta. È cresciuto nel tempo, il che significa che ci sono state molte modifiche. Qualsiasi modifica non completata è un errore di sintassi o un bug. Quindi non pretendo che sia carino. Affermo che aiuta a ottenere le modifiche giuste.

(E per quelli che dicono che dovrei passare una struttura, tutto ciò che fa è spostare il problema, perché hai bisogno di un sacco di righe di codice per riempire la struttura, per non parlare del codice aggiuntivo per dichiararlo e assegnarlo.)

Non lo definirei neanche io. La migliore pratica in cui ho lavorato è stata quella di avere tutte le chiamate di funzione su una sola linea, a meno che non si debba scorrere in orizzontale qualsiasi importo significativo per vedere l'intera chiamata. È un appello di giudizio, ma direi sicuramente che mettere tutte le funzioni in questo modo è fuori linea a meno che non sia lo standard stabilito dalla propria organizzazione.

Questo è il motivo per cui è buona prassi per un'organizzazione stabilire una serie di guide alle quali tutti i programmatori dovrebbero aderire. Si tratta di coerenza e leggibilità.

Semplifica:

• Riordina argomenti.
• Commenta o disabilita gli argomenti.
• Vedi esattamente quale argomento è cambiato quando visualizzi le differenze nel tuo sistema di controllo della versione
• Evita di rientrare nel rientro e di racchiudere le parole quando aggiungi o rimuovi un argomento o cambi il nome della funzione. (Anche se il tuo editor rientra automaticamente, stai comunque creando molte modifiche inutili agli spazi bianchi che rendono più difficile seguire le modifiche nel tuo sistema di controllo della versione.)

Direi che le chiamate di funzione dovrebbero essere tutte su una riga a meno che non superino in modo significativo la larghezza del codice standard (spesso 80 caratteri, spesso una causa di argomenti :-).

Non vedo alcun vantaggio in questo stile. Sembra soggettivamente brutto e lo trovo un dolore durante la ricerca del codice. Ad esempio, potresti voler cercare rapidamente e vedere se la funzione è mai stata chiamata con un determinato parametro passato come NULL. Questo è facile visivamente quando tutti i parametri sono su una riga e più difficile quando sono divisi in questo modo.

Ho spesso visto quello stile su dichiarazioni o definizioni di funzioni , ma mai su una chiamata (fino ad ora). Lì a volte ha senso in quanto consente di aggiungere un commento per i singoli parametri in modo più chiaro. Sembra che abbia copiato quello stile in chiamate senza conoscere veramente le ragioni sottostanti. Hai una buona argomentazione contro e non sembra che ne abbia una buona, quindi hai il mio voto, ma non sono io quello che devi convincere.

È contrario agli standard di codifica dell'azienda?

In caso contrario, avvia una discussione sugli standard e su cosa le persone vorrebbero vedere cambiate. Assicurati di presentarlo come una delle cose che vorresti cambiare.

Discuti a fondo sul perché non ritieni che ciò sia utile e spero che vincerai la giornata. Non sai mai che il tuo collega potrebbe convincerti che la sua strada è la migliore dopo tutto;)

Una volta che hai uno standard aggiornato, è documentato ciò a cui tutti dovrebbero codificare, quindi se il tuo collega persiste nel farlo, puoi aumentarlo nelle sue revisioni del codice.

Può sembrare strano, ma semplifica il lavoro sul codice. Durante il refactoring puoi commentare i singoli argomenti molto facilmente e controllare il tuo refactor prima di eliminare effettivamente le cose. Puoi anche commentare e sostituire temporaneamente i tipi abbastanza facilmente.

È anche più facile da leggere rispetto a:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

Non sono andato così estremo come stai mostrando (dal momento che non ci sono nomi sui parametri non è molto utile), ma ho preso l'abitudine di dividere ogni parametro sulla sua stessa linea o di non fare alcuna divisione.

La parte importante è che il tuo codice può essere stampato o visualizzato su display standard da 80col ed essere comunque leggibile.

Raramente otterrai una risposta onesta da un programmatore per qualcosa del genere. Tutti risponderanno semplicemente con ciò che fanno o non preferiscono. La verità è che, per quanto tutti noi lottiamo con essa a volte, l'unica "cattiva pratica" qui è la tua inflessibilità.

Devi essere brutalmente onesto con te stesso per essere in grado di distinguere tra cose che sono effettivamente cattive e cose che ti infastidiscono. La verità è che in C / C ++ e linguaggi simili raramente troverai una pratica di rientro che ha un effetto tangibile sulla comprensibilità del codice. La maggior parte delle discussioni su questo genere di cose ha solo le parti in comune con persone che fanno argomentazioni ridicole e disingenue per cercare di giustificare le proprie preferenze personali.

Quale alla mia lettura ... è esattamente quello che mi stai chiedendo in questa domanda: un argomento ridicolo e disingenuo per giustificare le tue preferenze personali.

A dire il vero dipende dalla persona .. Direi per funzioni complesse come dimostrato dal primo esempio di FrustratedWithForms, quindi sì; altrimenti un grande NO. Quindi di nuovo questo è il motivo per cui preferisco applicare arbitrariamente la funzionalità IDE del codice.

"Sono interessato a sapere se questa è in realtà una cattiva pratica ..."

Sì, è una cattiva pratica, tranne quando l'elenco delle variabili è insolitamente lungo. Ma in quel caso, il problema è probabilmente dovuto al design della funzione. Perché non passare un oggetto che incapsula molti parametri?

"... e se sì, come posso convincerli a non farlo?"

Legali e continua a solleticare finché non accettano di fermare quella merda.

Perché stai sprecando cicli su una preoccupazione così banale? Basta accendere il tuo IDE fidato, aprire il file e riformattare. Ecco! Sarà in qualunque forma tu voglia.

Passiamo ora alla questione davvero importante: vi o emacs, LOL.

Direi che se gli argomenti si adattano su una riga, fallo. In caso contrario, un argomento per riga garantisce un'ottima leggibilità.

foo(arg1, arg2, arg3, arg4, arg5)

vs.

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)