Best practice per il numero di argomenti per le subroutine in C

Question

Ho iniziato a lavorare sullo sviluppo di API scritte in C. Vedo alcune subroutine che prevedono 8 (otto) parametri e per me sembra brutto e ingombrante passare 8 parametri durante la chiamata quella particolare subroutine. Mi stavo chiedendo se fosse possibile implementare una soluzione più accettabile e più pulita.

Answer 1

8 potrebbe essere un numero corretto. oppure potrebbe essere che molti di quegli 8 dovrebbero appartenere tutti a una classe appropriata come membri, quindi potresti passare una singola istanza della classe ... difficile da dire solo da questo tipo di discussione ad alto livello.

modifica: in c - le classi sarebbero simili alle strutture in questo caso.

Answer 2

Un numero elevato di argomenti in una chiamata di funzione di solito mostra un problema di progettazione. Esistono modi per ridurre apparentemente il numero di parametri, con mezzi come la creazione di strutture che vengono trasmesse al posto delle singole variabili o aventi variabili globali. Ti consiglierei di NON fare nessuna di queste cose e di occuparti del design. Nessuna correzione rapida o semplice, ma le persone che devono mantenere il codice ti ringrazieranno per questo.

Answer 3

Se l'API sembra macchinosa con molti parametri, utilizzare un puntatore a una struttura per passare i parametri che sono relativi a in qualche modo.

Non ho intenzione di giudicare il tuo progetto senza vederlo in prima persona. Esistono funzioni legittime che richiedono un numero elevato di parametri, ad esempio:

1. Filtri con un numero elevato di coefficienti polinomiali.
2. Lo spazio colore si trasforma con maschere sub-pixel e indici LUT.
3. Aritmetica geometrica per poligoni irregolari n-dimensionali.

Ci sono anche alcuni progetti molto poveri che portano a grandi prototipi di parametri. Condividi maggiori informazioni sul tuo design se cerchi risposte più precise.

Answer 4

Se un numero di argomenti può essere raggruppato logicamente, si può prendere in considerazione la creazione di una struttura che li contiene e semplicemente passare tale struttura come argomento. Ad esempio, invece di passare due valori di coordinate x e y, potresti invece passare una struttura POINT.

Ma se un tale raggruppamento non è applicabile, allora qualsiasi numero di argomenti dovrebbe andare bene se davvero ne hai bisogno, anche se potrebbe essere un segnale che la tua funzione fa un po 'troppo e che potresti diffondere il lavoro su più , ma funzioni più piccole.

Answer 5

Uno schema utilizzato da alcune API (come pthreads) è "oggetti attributo" che vengono passati a funzioni anziché a un gruppo di argomenti discreti. Questi oggetti attributo sono strutture opache, con funzioni per creare, distruggere, modificare e interrogare. Tutto sommato, questo richiede più codice che semplicemente scaricare 10 argomenti in una funzione, ma è un approccio più solido. A volte un po 'di codice in più che può rendere il tuo codice molto più comprensibile vale lo sforzo.

Ancora una volta, per un buon esempio di questo modello, vedere l'API pthreads. Ho scritto a lengthy article sul design dell'API pthreads un paio di mesi fa, e questo è uno degli aspetti che ho affrontato.

Answer 6

Sembra anche interessante considerare questa domanda non dal punto di vista della bruttezza/non della bruttezza, ma dal punto di vista della performance.

So che ci sono alcuni x86 calling conventions che possono utilizzare i registri per passare due primi argomenti e lo stack per tutti gli altri argomenti. Quindi penso che se si usa questo tipo di convenzione di chiamata e si usi sempre un puntatore per strutturare per passare argomenti in situazioni quando una funzione ha bisogno di più di 2 parametri nel complesso, la chiamata di funzione potrebbe essere più veloce. Sui registri Itanium vengono sempre utilizzati per passare i parametri a una funzione.

Penso che valga la pena provare.

Answer 7

Sì, 8 è quasi certamente troppo.

Ecco alcuni termini di ingegneria del software della vecchia scuola per voi. Coesione e accoppiamento Cohesion è il modo in cui una subroutine tiene insieme da sola, e coupling è la pulizia delle interfacce tra le routine (o quanto sono autosufficienti le routine).

Con l'accoppiamento, generalmente il più flessibile, meglio è. L'interfacciamento solo tramite parametri ("accoppiamento dati") è un buon accoppiamento basso, mentre l'uso di variabili globali ("accoppiamento comune") è un accoppiamento molto elevato. Quando si dispone di un numero elevato di parametri, ciò che è solitamente il caso è che qualcuno ha cercato di nascondere il loro accoppiamento comune con un rivestimento sottile di accoppiamento dati. Il suo cattivo design con un lavoro di verniciatura.

Con coesione, più alto (più coesivo), meglio è. Qualsiasi routine che modifica otto cose diverse è anche abbastanza facile da soffrire di bassa coesione. Dovrei vedere il codice per vedere di sicuro, ma sarei disposto a scommettere che sarebbe molto difficile spiegare chiaramente cosa fa questa routine in una frase breve. Vista invisibile, direi che è temporalmente coesa (solo un mucchio di cose che devono essere fatte all'incirca nello stesso periodo).

Answer 8

Suggerisco anche l'uso di strutture. Forse vuoi ripensare il design delle tue API.

Ricordare che le API verranno utilizzate dagli sviluppatori e sarebbe difficile utilizzare una chiamata di funzione a 8 parametri.

Answer 9

Un'altra cosa che puoi fare è convertire alcuni dei parametri per dichiarare. funzioni OpenGL avere un minor numero di parametri perché hai chiamate come:

glBindFramebuffer(..) ; 
glVertexAttribPointer(..) ; 
glBindTexture(..) ; 
glBindBuffer(..) ; 
glBindVertexArray(..) ; 

// the actual draw call 
glDrawArrays(..) ; 

Tutti questi (chiamate glBind* tipo) rappresentare "cambiamento di stato", ognuno dei quali influenzeranno la chiamata sorteggio successivo. Immagina una chiamata con 20 argomenti, assolutamente ingestibili!

Anche la vecchia API di Windows C per il disegno era di stato, memorizzata negli oggetti "puntatore opaco" (HDC, HWND ..). Un puntatore opaco è fondamentalmente il modo in cui C crea membri di dati privati ​​a cui non è possibile accedere direttamente. Ad esempio, nell'API di disegno di Windows, si creerebbe un puntatore opaco HDC tramite createDC. È possibile impostare i valori interni della DC tramite le funzioni , ad esempio SetDCBrushColor.

Ora che si dispone di un controller DC con un colore e tutto, è possibile utilizzare la funzione Rectangle per disegnare nella CC. Hai passato un HDC come primo parametro, che conteneva informazioni su quale pennello colore usare ecc. Rectangle prende solo 5 parametri, lo hdc, x, y, larghezza e altezza.