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

was wondering if there is any reason other than personal preference why people use the second style?

Questo è uno stile che era popolare agli inizi di C, quindi la ragione potrebbe essere che è così che lo hanno fatto per molto tempo, hanno un sacco di codice che sembra così, e questo è ciò a cui tutti sono abituati. Non tanto le preferenze personali quanto lo slancio aziendale.

Un altro motivo è che i nomi delle funzioni iniziano sempre nella prima colonna. I tipi di ritorno variano in lunghezza e possono essere alquanto complessi: mettere il tipo sulla propria riga rende più facile trovare il nome della funzione.

Se la società ha uno stile impostato, potrebbe anche avere un documento di standard di codifica. Chiedi. Può spiegare il motivo (i) per questa scelta, e avere una copia ti aiuterà a evitare problemi simili nelle revisioni future.

Questa è praticamente l'unica regola di formattazione del codice che ho trovato in realtà ha un notevole impatto sulla leggibilità e non ci vuole quasi nessuno sforzo (presupponendo che l'editor di codice non inizi a litigare su di esso)

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

È come quando si sta formattando un documento: quando si inizia una nuova sezione, si mette il nome davanti in grassetto - spesso sulla propria linea - non sepolto da qualche parte, indifferenziato, in una lunga frase.

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

double dot(x, y);

È ancora abbastanza digeribile.

C ++ ha reso questo un po 'peggio. Ha spostato le specifiche del tipo di argomento in firme rendendo più lunghe 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)

Considerate ora le pratiche di programmazione moderne con nomi lunghi e descrittivi e tipi parametrizzati e vedete 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 dall'ordinario. Puoi trovare esempi di casi molto peggiori di questo senza tentare troppo.

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

Ho incontrato per la prima volta questo stile come il 19 ° anno di lavoro con C & C ++. Era piuttosto sconcertato su 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 un fattore rilevante più di dieci anni fa in alcune comunità di odiatori di strumenti reali ... Nel luogo in cui ho visto è stato applicato al C ++ e ai funcitons dei membri della classe, che uccidono persino questo attributo.

Indovina la mia opinione. :)