Perché gli sviluppatori di C # newline aprono le parentesi? [chiuso]

37

Ho passato la maggior parte degli ultimi anni a lavorare principalmente con C # e SQL. Ogni programmatore con cui ho lavorato in quel periodo aveva l'abitudine di posizionare la parentesi di apertura di una funzione o di una dichiarazione di flusso di controllo su una nuova riga. Quindi ...

public void MyFunction(string myArgument)
{
     //do stuff
}

if(myBoolean == true)
{
    //do something
}
else
{
    //do something else
}

Sono sempre stato colpito da quanto spreco di spazio è questo, specialmente nelle dichiarazioni if / else. E so che esistono alternative nelle versioni successive di C #, come:

if(myBoolean == true)
    //do something on one line of code

Ma quasi nessuno li ha usati. Ognuno ha fatto il riccio-brace-on-newline cosa.

Poi sono tornato a fare JavaScript dopo una lunga assenza. Nella mia memoria, gli sviluppatori di JavaScript erano soliti fare la stessa identica cosa di riccio-brace, ma con tutte le nuove fantasiose librerie e roba, la maggior parte degli sviluppatori ha messo la parentesi aperta dopo la dichiarazione:

function MyJavaScriptFunction() {
    //do something
}

Puoi vedere il senso in questo, perché poiché l'utilizzo di chiusure e puntatori di funzione è diventato popolare in JavaScript, risparmia molto spazio e rende le cose più leggibili. Quindi mi sono chiesto perché non è stato visto come la cosa fatta in C #. Infatti, se provi il costrutto sopra in Visual Studio 2013, in realtà lo riformatta per te, mettendo la parentesi aperta su una nuova riga!

Ora ho appena visto questa domanda su Code Review SE: link In cui ho imparato che in Java, una lingua con cui non ho molta familiarità, è considerato di rigore aprire le parentesi graffe subito dopo la dichiarazione, nella moderna modalità JavaScript.

Ho sempre capito che C # è stato originariamente modellato su Java e mantenuto molti degli stessi standard di codifica basale. Ma in questo caso, non sembra. Quindi presumo ci debba essere una buona ragione: qual è la ragione? Perché gli sviluppatori C # (e Visual Studio) impongono l'apertura di parentesi graffe su una nuova riga?

    
posta Matt Thrower 25.04.2014 - 15:07
fonte

4 risposte

62

La coppia alla fine della linea è l'antico standard K & RC, da Brian Kernighan e il libro di Dennis Ritchie The C Programming Language , che hanno pubblicato nel 1978 dopo aver co-inventato il sistema operativo UNIX e il linguaggio di programmazione C (penso che C fosse per lo più disegnato da Ritchie), in AT & T;

In passato c'erano guerre di fiamma su "l'unico vero stile di coppia".

Ritchie ha inventato il linguaggio C e Kernighan ha scritto il primo tutorial, quando le schermate del computer mostravano solo alcune righe di testo. Infatti, lo sviluppo di UNICS (successivamente UNIX) è iniziato su un DEC PDP-7, che utilizzava una macchina da scrivere, una stampante e un nastro di carta per un'interfaccia utente. UNIX e C erano finiti sul PDP-11, con terminali di testo a 24 righe. Quindi lo spazio verticale era davvero un premio. Oggi abbiamo tutti display leggermente migliori e stampanti con risoluzione più elevata, giusto? Voglio dire, non so voi, ma ho tre (3) schermi da 1080p da 24 "davanti a me in questo momento.: -)

Inoltre, gran parte di quel piccolo libro Il linguaggio di programmazione C è codice campioni che mettevano le parentesi graffe alle estremità delle linee anziché sulle proprie linee avrebbero presumibilmente salvato una notevole quantità di denaro sulla stampa.

Ciò che è veramente importante è la coerenza in tutto il progetto, o almeno all'interno di un determinato file di codice sorgente.

sono anche studi scientifici che dimostrano che il tutore su una propria linea (indentato allo stesso livello del codice, in effetti) migliora la comprensione del codice nonostante ciò che la gente pensa di pensare all'estetica. Rende molto chiaro al lettore, visivamente e istintivamente, quale codice viene eseguito in quale contesto.

if( true )
    {
    // do some stuff
    }

C # ha sempre supportato valutando un singolo comando dopo un'espressione di ramificazione, a proposito. In effetti, questa è l'unica cosa che fa, anche adesso. Mettere il codice tra parentesi dopo un'espressione di branching rende solo un comando a goto (il compilatore crea scope usando le istruzioni jmp). C ++, Java, C # e JavaScript sono tutti più o meno basati su C, con le stesse regole di analisi di base, per la maggior parte. Quindi in questo senso, C # non è "basato su Java".

Riassumendo, questo è un po 'di un problema religioso / di guerra di fiamma. Ma gli studi sono rendono abbastanza chiaro che l'organizzazione del codice nei blocchi migliora la comprensione umana . Al compilatore non potrebbe importare di meno. Ma questo è anche legato al motivo per cui non ho mai messo una riga di codice dopo un ramo senza parentesi graffe - è semplicemente troppo facile per me o un altro programmatore schiaffeggiare un'altra riga di codice in seguito e far passare il fatto che non lo farà eseguire nello stesso contesto con la linea subito prima o dopo.

EDIT : vai a consultare il bug goto fail di Apple per un perfetto esempio di questo problema esatto, che ha avuto conseguenze molto serie sul mondo reale.

if( true )
    doSomething();

diventa ...

if( true )
    doSomething();
    doSomethingElse();

In questo caso, doSomethingElse() viene eseguito ogni volta, indipendentemente dall'esito del test, ma poiché è rientrato allo stesso livello dell'istruzione doSomething() , è facile perdere. Questo non è davvero discutibile; studi lo confermano. Questa è una grande fonte di bug introdotti nel codice sorgente durante la manutenzione.

Tuttavia, ammetto che la sintassi della chiusura JavaScript sembra un po 'sciocca con le parentesi graffe sulle proprie linee ... esteticamente. : -)

    
risposta data 25.04.2014 - 16:37
fonte
27

Il motivo per cui gli sviluppatori C # lo fanno è perché è l'impostazione predefinita del formattatore automatico di Visual Studio. Sebbene questa impostazione possa essere modificata, la maggior parte delle persone non lo fa, e quindi tutti gli sviluppatori di un team devono andare con la maggioranza.

Per quanto riguarda il motivo per cui questo è l'impostazione predefinita in Visual Studio, non lo so.

    
risposta data 25.04.2014 - 16:32
fonte
15

Come ho ipotizzato in questa risposta qui - link - Suppongo che la decisione di andare con il rinforzo di Allman potrebbe essere un segno dell'eredità pasquale, dato che Hejlsberg creò Delphi prima di progettare il C #. Uguale al caso Pascal per i nomi dei metodi.

Personalmente credo nel seguire l'adagio "a Roma come fanno i romani". Uso Allman's in C #, ma K & R in Java. Sono così abituato che cambiare la convenzione in entrambi i casi mi sconvolge.

Credo che una certa diversità di convenzioni sia effettivamente vantaggiosa per uno sviluppatore "multilingue" in quanto aiuta a ricordare quale lingua stanno codificando al momento e rende facile distinguere le varie abitudini. È un equivalente mentale della memoria muscolare, per così dire.

    
risposta data 25.04.2014 - 16:59
fonte
12

La convenzione che si associa a Java è lo stile di K & R, o il "One true brace style", e viene originariamente da C. Questa pagina indent-style dal venerabile file Jargon mostra quanti anni ha la distinzione.

Ho sempre pensato che lo stile Allman e le sue varianti riflettessero il modo in cui gli autori pensano al codice, elevando i delimitatori di blocco al livello di parole chiave simili a come alcune lingue usano "begin" e "end" attorno ai blocchi di codice.

    
risposta data 25.04.2014 - 16:26
fonte

Leggi altre domande sui tag