Motivo per posizionare il tipo di funzione e il nome del metodo su diverse righe in C

Ho appena iniziato in una società e uno dei commenti di stile alla mia prima recensione del codice era che il tipo di ritorno e il nome del metodo dovrebbero essere su linee diverse. Ad esempio, questo

void foo() {
}

dovrebbe essere questo

void
foo() {
}

Ho sempre usato il primo stile e mi chiedevo se ci fosse un motivo diverso dalle preferenze personali per cui le persone usano il secondo stile? Non credo che il primo danneggi affatto la leggibilità. Uno è più comune dell'altro con programmatori C e grandi progetti open source?

mi chiedevo se ci fosse qualche ragione diversa dalla preferenza personale per cui le persone usano il secondo stile?

Questo è uno stile che era popolare ai primi tempi di C, quindi la ragione potrebbe essere che è così che lo hanno fatto per molto tempo, hanno un sacco di codice simile a quello, ed è quello che tutti sono abituati. Non tanta preferenza personale quanto lo slancio aziendale.

Un altro motivo è che i nomi delle funzioni iniziano sempre nella prima colonna. I tipi di restituzione possono variare in lunghezza e possono essere alquanto complessi: posizionarli sulla propria riga semplifica la ricerca del nome della funzione.

Se la società ha uno stile prestabilito, potrebbe anche avere un documento sugli standard di codifica. Chiedi. Potrebbe spiegare i motivi di questa scelta e avere una copia ti aiuterà a evitare problemi simili nelle recensioni future.

Questa è praticamente l'unica regola di formattazione del codice che ho trovato in realtà ha un impatto notevole sulla leggibilità e non richiede quasi sforzo (supponendo che il tuo editor di codice non inizi a litigare con te su di esso).

È buona norma progettare un linguaggio di programmazione per far apparire i nomi in una posizione coerente nelle dichiarazioni / definizioni. La logica è semplice: hai una bella ancora visiva (una parentesi graffa o solo una rientranza sospesa) che puoi usare per trovare immediatamente l'inizio del nome. Non è necessario analizzare effettivamente la lingua durante la scansione di un file per trovare il nome.

È lo stesso di quando stai formattando un documento: quando inizi una nuova sezione metti il ​​nome in grassetto - spesso sulla sua stessa linea - non sepolto da qualche parte, indifferenziato, in una lunga frase.

I primi C avevano firme molto concise: i tipi di restituzione erano facoltativi e i tipi di argomento venivano dichiarati dopo la firma. Anche i nomi tendevano ad essere molto brevi. Ciò ha mitigato l'impatto di un tipo di ritorno occasionale che compensa il nome.

double dot(x, y);

È ancora abbastanza digeribile.

Il C ++ ha peggiorato le cose. Ha spostato le specifiche del tipo di argomento in firme allungando le firme. Questa sintassi è stata successivamente adottata durante la standardizzazione di C.

static struct origin *find_origin(struct scoreboard *sb,
                  struct commit *parent,
                  struct origin *origin)

è meno digeribile, ma non troppo male. (Estratto da Git)

Ora considera le moderne pratiche di programmazione con nomi lunghi e descrittivi e tipi parametrizzati e vedi come questa scelta è diventata disastrosa. Un esempio da un'intestazione Boost:

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

Se stai scrivendo un codice generico, firme del genere non sono nemmeno fuori dal comune. Puoi trovare esempi di casi molto peggiori di questo senza provarci troppo.

C, C ++ e i loro derivati, Java e C #, sembrano essere le eccezioni ad avere dichiarazioni / definizioni leggibili. I loro predecessori e colleghi popolari (Fortran, ALGOL, Pascal) hanno posto i nomi prima dei tipi di risultati e, per fortuna, molti dei loro successori (Go, Scala, TypeScript e Swift per citarne alcuni) hanno scelto anche sintassi più leggibili.

Ho incontrato questo stile per la prima volta come nel 19 ° anno di lavoro con C & C ++. Era piuttosto sconcertato da come qualcuno potesse inventare questa cosa malvagia.

L'unico punto (potenzialmente) positivo che ho trovato è che puoi trovare la definizione di funciton usando grep ^ FuncName. Potrebbe essere rilevante fattore decennio + fa in alcune comunità di odio di strumenti reali ... Nel luogo in cui ho visto che era applicato al C ++ e alle funzioni dei membri della classe, che uccidono anche questo attributo.

Indovina la mia opinione. :)