Mentre una struct crea un sovraccarico in fase di esecuzione, il confezionamento di una serie di variabili di uso frequente può aumentare notevolmente la leggibilità del codice. Come bilanciate i due? Mi è stato solo chiesto di "srotolare" una struttura che conteneva 12 variabili, che ora effettua chiamate all'intestazione della funzione monolitica; sembra uno stile povero e volevo sapere cosa pensavano gli altri.
Quante funzioni hai che utilizza quei parametri?
Se hai 4 funzioni che prendono tutti gli stessi 12 parametri, è un segno che probabilmente dovresti raggrupparli in un set coesivo.
Se hai 4 funzioni che usano dire ... 8 dei parametri, allora forse quelle 8 dovrebbero essere raggruppate.
Ma questo piuttosto manca un po 'di punto. Il raggruppamento in una struttura non è la tua unica opzione. Puoi anche suddividere la funzione in modo che invece di una grande funzione che richiede 12 parametri, hai 8 più focalizzati che necessitano di uno o due parametri. Le funzioni più piccole sono più facili da testare, più facili da riutilizzare, più facili da scrivere, più facili da gestire.
Tenere presente che in genere la soluzione non collassa sempre alcuni argomenti in una struttura dati distinta. La maggior parte delle volte dovresti dividere le funzioni in più perché probabilmente è la funzione stessa che fa più cose.
Ricordo lo zio Bob in Pulisci codice che dice che ci dovrebbero essere al massimo 2 e solo in casi speciali 3 argomenti per una funzione. Questo potrebbe essere molto difficile da ottenere tutto il tempo (prendi per esempio funzioni con timeout in cui timeout e timeunit richiedono 2 argomenti).
D'altro canto Code Complete non è così rigoroso, dicendo che non dovrebbero esserci più di 7, ma sottolineando il fatto che nei linguaggi di livello superiore ciò può essere evitato.
Leggi altre domande sui tag coding-style readability