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

È solo una linea guida di programmazione che potresti o non vorresti gradire. L'importante è che tu e i tuoi colleghi accettiate 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 complicate in cui si desidera documentare ciascun parametro o dove le variabili sono piuttosto lunghe e ce ne sono molte, può essere utile.

Ad 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 che se la chiamata alla funzione è semplice e non ci sono troppi parametri, questo potrebbe diventare fastidioso, come ad esempio:

setColour (
    r,
    g,
    b
 );

Trovo molto più facile 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 è raro è cattiva pratica a meno che la superiorità rispetto al solito stile possa essere provata positivamente. "La materia del gusto" è una scusa scusa per scrivere un 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 è raro è relativamente facile, mostrare la fonte di esempi in MSDN o siti simili, mostrare grandi basi di codici open source ecc. Mostrare l'output degli abbellitori di codice. In definitiva, mostra come mai il resto del team tuo lo sta facendo. Non accettare uno stile cattivo solo perché qualcuno è troppo testardo.

Non lo chiamerei neanche io. Le best practice in cui ho lavorato sono state in genere le chiamate di funzione su una sola riga, a meno che non si debba scorrere in senso orizzontale qualsiasi importo significativo per vedere l'intera chiamata. È un giudizio, ma direi sicuramente che mettere tutte le funzioni tutte come questa è fuori linea a meno che non sia lo standard stabilito dalla tua organizzazione.

Ecco perché è buona prassi per un'organizzazione stabilire una serie di guide alle quali tutti i programmatori dovrebbero aderire. È tutto basato sulla coerenza e leggibilità.

Bene, ecco un po 'esca per difetto. Non sono mai stato accusato di fare la cosa popolare. Chiaramente, se le cose si adattano su una riga, quindi bene, adattarle su una riga.

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 linee separate? A mio avviso ciò rende più facile vedere quali sono e più facilmente modificarli se necessario. Mi dà anche spazio per allegare un commento a ciascun argomento, se lo desidero.

Voglio anche ridurre al minimo la possibilità di commettere un errore se aggiungo o rimuovi un argomento a una funzione, che è più probabile che accada alla fine di un elenco di argomenti rispetto all'inizio. Per questo motivo, preferisco inserire la virgola (,) all'inizio di una riga, che alla fine. Quindi, se per esempio, voglio 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 l'ultima, in cui l'ultima deve terminare con una parentesi.

Quindi (ragazzo, vengo fiammeggiato 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 ha ottenuto tutto in una 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 ritengo che sia carino. Sostengo che aiuti a ottenere le modifiche giuste.

(E per quelli che dicono che dovrei passare una struttura invece, tutto ciò che fa è spostare il problema, perché hai bisogno di un mucchio di linee di codice per riempire la struttura, per non parlare del codice aggiuntivo da dichiarare e allocarlo .)

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

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

Rende più facile:

• Riordina argomenti
• Commenta o disattiva gli argomenti.
• Visualizza esattamente quale argomento è cambiato quando si visualizzano le differenze nel proprio sistema di controllo della versione
• Evita il rientro e il ritorno a capo di tutto quando aggiungi o rimuovi un argomento o cambia il nome della funzione. (Anche se il tuo editor viene automaticamente indentato, stai ancora creando molte modifiche dello spazio bianco inutili che rendono più difficile seguire le modifiche nel tuo sistema di controllo della versione.)

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

È contro gli standard di codifica dell'azienda?

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

Fai una discussione completa su perché non pensi che sia utile e spero che vinci 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 su cosa dovrebbero essere codificati tutti, quindi se il tuo collega continua a farlo puoi farlo nelle sue recensioni del codice.

Potrebbe sembrare strano, ma rende più semplice lavorare sul codice. Durante il refactoring è possibile commentare facilmente gli argomenti individuali e controllare il refactoring 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 (dato che non ci sono nomi sui parametri che non è molto utile), ma ho preso l'abitudine di dividere ogni parametro sulla sua stessa linea o non farlo dividere in tutti.

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

Raramente otterrai una risposta onesta da un programmatore per qualcosa di simile. Tutti risponderanno semplicemente con quello che fanno o non preferiscono. La verità è che, per quanto tutti ci dibattiamo 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 in linguaggi simili raramente troverai una pratica di indentazione che ha un impatto tangibile sulla comprensibilità del codice. La maggior parte delle discussioni su questo genere di cose hanno entrambe le parti impilate con persone che fanno argomentazioni ridicole e ingenue per cercare di giustificare le loro preferenze personali.

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

Per essere onesti dipende dalla persona .. Direi per le funzioni complesse come dimostrato dal primo esempio di FrustratedWithForms, poi sì; altrimenti un grande NO. Quindi, ancora una volta è per questo che preferisco applicare la funzionalità IDE del codice arbitrariamente.

"Sono interessato a sapere se questa è una pratica sbagliata ..."

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

"... e in tal caso, come posso convincerli a non farlo?"

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

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

Passiamo ora al problema veramente importante - vi o emacs, LOL.

Direi che se gli argomenti si adattano a una riga, fallo. In caso contrario, un argomento per riga offre 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
)