Le parentesi graffe dovrebbero essere sulla propria linea o no? Cosa ne pensi?
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
o dovrebbe essere
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
o anche
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
Per favore sii costruttivo! Spiega perché, condividi esperienze, esegui il backup con fatti e riferimenti.
Quando ero uno studente mettevo le parentesi graffe sulla stessa linea, in modo che ci fossero meno righe e il codice venisse stampato su meno pagine. Guardare un singolo carattere di parentesi stampato come l'unica cosa in una linea è fastidioso. (ambiente, spreco di carta)
Ma quando si codificano applicazioni di grandi dimensioni, alcune linee con solo parentesi graffe sono accessibili, considerando la sensazione di "raggruppamento" che dà.
Indipendentemente dallo stile scelto, coerente in modo che non diventi un overhead per il tuo cervello per elaborare più stili in parti di codice correlate . In diversi scenari (come sopra) direi che va bene usare stili diversi, è più semplice "cambiare contesto" ad un livello elevato.
Non devi mai fare il terzo metodo.
La possibilità di ignorare le parentesi graffe potrebbe farti risparmiare alcune combinazioni di tasti la prima volta, ma il prossimo programmatore che arriva, aggiunge qualcosa alla tua clausola else senza notare che le parentesi graffe non sono presenti per molto dolore.
Scrivi il tuo codice per altre persone.
Per molto tempo ho sostenuto che erano di valore uguale, o così molto vicino alla pari che il guadagno possibile facendo la scelta giusta era di gran lunga inferiore al costo di sostenendo a riguardo.
Essere coerente è importante , però. Quindi ho detto di lanciare una moneta e scrivere codice.
Ho visto i programmatori resistere a cambiamenti come questi prima. Farsene una ragione! Sono passato molte volte nella mia carriera. Uso anche stili diversi nel mio C # rispetto al mio PowerShell.
Alcuni anni fa stavo lavorando a un team (circa 20 sviluppatori) che ha deciso di chiedere l'input, e quindi prendere una decisione, e quindi applicarla a tutti i codici base. Avremmo 1 settimana per decidere.
Un sacco di gemiti e amp; strabuzzare gli occhi. Un sacco di "Mi piace il mio modo, perché è meglio" ma senza sostanza.
Mentre stavamo studiando i punti più fini della domanda, qualcuno ha chiesto come affrontare questo problema in uno stile che combacia con la stessa linea:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Si noti che non è immediatamente ovvio dove finisce l'elenco dei parametri e inizia il corpo. Confronta con:
void MyFunction(
int parameterOne,
int parameterTwo)
{
int localOne,
int localTwo
}
Abbiamo fatto alcune letture su come le persone di tutto il mondo si sono occupate di questo problema e abbiamo trovato lo schema per aggiungere una riga vuota dopo la parentesi aperta:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Se hai intenzione di fare un'interruzione visiva, puoi farlo anche con un tutore. Anche le tue interruzioni visive diventano coerenti.
Modifica : due alternative alla soluzione "extra blank line" quando usi K & R:
1 / Indenta gli argomenti della funzione in modo diverso dal corpo della funzione
2 / Metti il primo argomento sulla stessa riga del nome della funzione e allinea gli ulteriori argomenti sulle nuove linee a quel primo argomento
Esempi:
1 /
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
2 /
void MyFunction(int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
/ Modifica
Continuo a sostenere che la coerenza è più importante di altre considerazioni, ma se non abbiamo un precedente stabilito , allora brace-on-next-line è la strada da percorrere.
Le regole cardinali sono:
Anche se non hai vincoli esterni su di te, è preferibile (IMO) cercare una norma di codifica o uno standard di codifica esistente (ampiamente utilizzata) e provare a seguirla. Se sviluppi il tuo stile, ci sono buone probabilità che tu possa venire a pentirsene tra qualche anno.
Infine, uno stile implementato / implementabile usando i controlli di stile e i formattatori di codice esistenti è meglio di uno che deve essere "forzato" manualmente.
Il vantaggio del primo metodo è che è più verticalmente compatto, quindi è possibile inserire più codice sullo schermo, ed è per questo che lo preferisco. L'unica argomentazione che ho ascoltato a favore del secondo metodo è che semplifica l'accoppiamento delle parentesi di apertura e chiusura, ma la maggior parte degli IDE hanno una scorciatoia da tastiera per questo, ed è in realtà una falsa dichiarazione- invece di accoppiare una parentesi aperta ad una chiusura parentesi è possibile associare una parentesi di chiusura all'espressione "start of block" (if, else, for, while) sullo stesso livello di indentazione, quindi è altrettanto facile determinare dove è l'inizio del blocco.
Non vedo alcun motivo per sprecare un'intera linea solo per una parentesi quando il costrutto precedente for / while / if indica visivamente l'inizio di un blocco.
Detto questo, credo che la parentesi di chiusura dovrebbe essere nella sua stessa linea perché abbiamo bisogno di qualcosa per indicare la fine di un blocco e la sua struttura di indentazione in modo visibile.
Preferisco
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
su
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
perché la riga you.postAnswer(); è molto più facile da leggere e trovare a prima vista. Nel secondo modo, si mescola con la linea sopra di esso ( you.hasAnswer() ), costringendo i miei occhi a concentrarsi di più per leggerlo.
Preferisco il primo metodo. Le parentesi graffe non valgono assolutamente la linea separata.
Il fatto è che le parentesi non sono importanti. Sono solo cestino sintattico , che non è assolutamente necessario per capire a cosa serve il codice, del suo scopo e del modo in cui è implementato. Sono solo un tributo alle lingue simili a quelle del vecchio stile C in cui il raggruppamento visivo degli operatori era impossibile a causa del basso spazio disponibile sullo schermo.
Ci sono linguaggi (Python, Haskell, Ruby) che sono OK senza parentesi graffe. Questo conferma solo che le parentesi graffe sono spazzatura e che non dovrebbero meritare una riga per loro quando possibile:
if (you.hasAnswer()){
you.postAnswer();
}else{
you.doSomething();
}
La posizione delle parentesi graffe dovrebbe essere
metadati
configurabile nell'IDE dal programmatore. In questo modo, quelle fastidiose parentesi graffe in tutto il codice, indipendentemente dall'autore, sembrano uguali.
Dipende.
Se sto codificando in Javascript o jQuery, uso il primo modulo:
jQuery(function($) {
if ($ instanceOf jQuery) {
alert("$ is the jQuery object!");
}
});
Ma se sto codificando in C #, uso il secondo modulo, perché quello è il modo canonico di farlo in C #.
public int CalculateAge(DateTime birthDate, DateTime now)
{
int age = now.Year - birthDate.Year;
if (now.Month < birthDate.Month
|| (now.Month == birthDate.Month && now.Day < birthDate.Day))
age--;
return age;
}
Nota che il tuo esempio può essere scritto
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
in C #.
Preferisco il primo perché è più difficile per me vedere l'errore in questo esempio.
if (value > maximum);
{
dosomething();
}
di quanto non sia in questo esempio
if (value > maximum); {
dosomething();
}
Il ; { mi sembra più sbagliato di una riga che termina con ; , quindi è più probabile che me ne accorga.
Preferisco una leggera variante di 1)
if (you.hasAnswer()) {
you.postAnswer();
} // note the break here
else {
you.doSomething();
}
Perché?
Penso che sempre mettere le parentesi sulla propria linea diminuisca la leggibilità. Posso solo adattare una certa quantità di codice sorgente sul mio schermo. Bracket style 2) rende gli algoritmi heave con molti loop e condizioni condizionali annidati dolorosamente lunghi.
Tuttavia, voglio else per iniziare su una nuova riga perché if e else appartengono insieme, visivamente. Se c'è una parentesi davanti a else , è molto più difficile individuare ciò che appartiene a cosa.
3) si squalifica. Sappiamo tutti cosa possono accadere cose brutte se si omettono le parentesi e ci si dimentica.
Ho letto da qualche parte che gli autori di alcuni libri volevano il loro codice formattato in questo modo:
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
Ma i vincoli di spazio dei loro editori significavano che dovevano usare questo:
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
Ora non so se sia vero (come non riesco a trovarlo più), ma quest'ultimo stile è molto diffuso nei libri.
A livello personale preferisco le parentesi su una riga separata come:
a) indicano un nuovo ambito
b) è più facile da individuare quando hai una mancata corrispondenza (anche se questo è meno di un problema in un IDE che evidenzia errori per te).
Ah, lo One True Brace Style .
Ha tutto il necessario per una Via Santa - anche un profeta (Richard "a modo mio o l'autostrada" Stallman).
Il tizio era così sbagliato su così tante cose, ma GNU è azzeccato quando si tratta di parentesi graffe.
[Aggiornamento] Ho visto la luce e ora adoro Allman
Secondo esempio, sono molto grande sulla leggibilità. Non sopporto di guardare se blocchi in qualsiasi altro modo = (
Risposta semplice: cos'è più facile eseguire il debug?
// Case 1:
void dummyFunction() {
for (i = 0; i != 10; ++i) {
if (i <= 10)
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there";
}
} // COMPILER ERROR HERE
// Case 2:
void dummyFunction()
{
for (i = 0; i != 10; ++i)
if (i <= 10)
{
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there\n";
}
} // COMPILER ERROR HERE
In quale caso hai diagnosticato prima il problema?
Non mi importa molto delle preferenze personali (ci sono molti altri stili, inclusi whitesmith e al.) e non mi interessa molto ... purché non ostacoli la mia capacità di leggere il codice e debug it.
Per quanto riguarda l'argomento "spreco di spazio", non lo compro: tendo ad aggiungere comunque delle righe vuote tra i gruppi logici per rendere il programma più chiaro ...
Non che qualcuno se ne accorga, ma questo è il motivo per cui le parentesi appartengono alla stessa linea come condizionale (eccetto per condizionali molto lunghi, ma questo è un caso limite):
In C, questo è un costrutto valido:
while(true);
{
char c;
getchar(); //Wait for input
}
rapida! Cosa fa questo codice? Se hai risposto "loop infinito chiedendo input", hai torto! Non arriva nemmeno all'input. Viene rilevato a while(true) . Si noti che punto e virgola alla fine. Questo schema è in realtà più comune che sembra debba essere; C richiede di dichiarare le variabili all'inizio di un blocco, motivo per cui ne è stato avviato uno nuovo.
Una linea di codice è un pensiero. Le parentesi graffe sono una parte del pensiero che contiene il condizionale o il ciclo. Pertanto, appartengono alla stessa riga
Mi piace il primo metodo. Sembra IMO più ordinato, ed è più compatto, che mi piace.
EDIT: Ah, un terzo. Mi piace quello il meglio quando è possibile, in quanto è ancora più piccolo / più ordinato.
Potresti scriverlo:
you.hasAnswer() ? you.postAnswer() : you.doSomething();
Per rispondere alla domanda; Preferivo le parentesi graffe sulla propria linea, ma, per evitare di dover pensare ai bug dall'inserimento automatico del punto e virgola nei browser, ho iniziato a utilizzare lo stile egiziano per javascript. E quando codificava java in eclissi non avevo alcun interesse a combattere (oa configurare) lo stile di parentesi predefinito, quindi sono andato con l'egiziano anche in quel caso. Ora sto bene con entrambi.
Quasi tutte le risposte qui stanno dicendo alcune variazioni su "Qualunque cosa tu faccia, rimani con uno o due".
Quindi ci ho pensato per un momento, e ho dovuto ammettere che non lo considero così importante. Qualcuno può dirmi onestamente che quanto segue è difficile da seguire?
int foo(int a, Bar b) {
int c = 0;
while(a != c)
{
if(b.value[a] == c) {
c = CONST_A;
}
c++;
}
return c;
}
Non sono sicuro di nessun altro ... ma ho assolutamente zero problemi passando mentalmente avanti e indietro tra gli stili. Mi ci sono voluti alcuni minuti per capire che cosa fosse il codice, ma questo è il risultato di me semplicemente digitando casualmente la sintassi simile a C. :)
Nel mio non-così-umile parere, le parentesi graffe di apertura sono quasi completamente irrilevanti per la leggibilità del codice. Ci sono alcuni casi d'angolo sopra elencati in cui uno stile o l'altro fa la differenza, ma per la maggior parte, l'uso giudizioso delle righe vuote lo pulisce.
FWIW, i nostri stili di codifica al lavoro usano una forma leggermente più strutturata 1 e una forma modificata 3. (C ++)
// blank line is required here
if (x) {
//This blank line is required
y = z;
}
// blank line is required here too, unless this line is only another '}'
if (x) y = z; //allowed
if (x)
y = z; // forbidden
Sono curioso di sapere se coloro che preferiscono strongmente la forma 2 troveranno questa versione della forma 1 migliore, solo perché la linea vuota offre una separazione visiva più strong.
Sono sorpreso che questo non sia stato ancora sollevato. Preferisco il secondo approccio perché ti permette di selezionare il blocco più facilmente.
Quando le parentesi iniziano e finiscono sulla stessa colonna e sulla propria linea, è possibile selezionare dal margine o con il cursore sulla colonna 0. Ciò generalmente equivale a un'area più generosa con selezione del mouse o meno tasti con selezione da tastiera .
Originariamente lavoravo con parentesi graffe sulla stessa linea del condizionale, ma quando passai scoprii che accelerava la velocità con cui lavoravo. Non è giorno e notte, naturalmente, ma è qualcosa che ti rallenta leggermente lavorando con le parentesi accanto ai tuoi condizionali.
Personalmente mi piace il secondo modo.
Tuttavia, il modo in cui ho intenzione di dimostrare è a mio parere il migliore perché si traduce in maggiore sicurezza del lavoro! Un compagno di studi della mia università mi ha chiesto aiuto per i compiti e così è apparso il suo codice. L'intero programma sembrava un unico blocco. La cosa interessante è che il 95% degli errori nel programma che ha creato proveniva da parentesi graffe non corrispondenti. L'altro 5% era ovvio una volta che le parentesi erano abbinate.
while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
if(i%1==0){
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
if(i%1==0){
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='%pre%';
puts(input);
';
puts(input);
La mia preferenza personale è per il primo metodo, probabilmente perché è così che ho imparato PHP.
Per le dichiarazioni di riga singola if , userò
if (you.hasAnswer()) you.postAnswer();
Se non è you.postAnswer(); ma qualcosa di molto più lungo, come you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); probabilmente tornerò al primo tipo:
if (you.hasAnswer) {
you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}
Non userò mai un'interruzione di riga e non utilizzerò mai questo metodo se esiste anche un'istruzione else .
if (you.hasAnswer()) you.postAnswer();
else you.doSomething()
è una possibilità teorica, ma non una che utilizzerei mai. Questo dovrebbe essere trasformato in
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
Non dovrebbero; primo metodo per me.
Quando guardo il secondo, a causa delle linee inutilizzate (che hanno solo parentesi graffe su di esso, oltre all'ultima parentesi di chiusura), sembra che rompa la continuità del codice. Non riesco a leggerlo velocemente perché devo prestare particolare attenzione alle linee vuote che di solito significano una separazione nello scopo del codice o qualcosa del genere, ma in nessun caso "questa linea appartiene a una parentesi graffa" (che ripete solo il significato di indentazione).
Ad ogni modo, proprio come quando scrivi un testo ... aggiungere una rientranza all'inizio di un paragrafo è superfluo se c'è una riga vuota prima di esso (doppio segno di modifica del paragrafo), non è necessario sprecare le linee per le parentesi graffe quando indentiamo correttamente.
Inoltre, come già detto, consente di inserire più codice nello schermo, che altrimenti è un po 'controproducente.
Dipende dalla piattaforma / lingua / convenzioni
In Java:
void someMethod() {
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
}
In C #
void someMethod()
{
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
}
In C:
void someMethod()
{
if (you_hasAnswer()) {
you.postAnswer();
} else {
you_doSomething();
}
}
Odio quando i ragazzi di Java usano il loro stile nel codice C # e viceversa.
Tutto quello che posso dire è che se sei un fan del metodo # 3, sarai perseguitato da tutti i programmi di formattazione IDE sulla terra.
Uso il primo metodo semplicemente perché è più compatto e consente più codice sullo schermo. Io stesso non ho mai avuto problemi con l'accoppiamento di parentesi graffe (li scrivo sempre insieme alla dichiarazione if prima di aggiungere la condizione, e la maggior parte degli ambienti consente di passare alla parentesi corrispondente).
Se hai bisogno di accoppiare le parentesi visivamente, allora preferirei il secondo metodo. Tuttavia, ciò consente meno codice in una volta, il che richiede di scorrere di più. E questo, almeno per me, ha un impatto maggiore sulla lettura del codice rispetto all'utilizzo di parentesi graffe perfettamente allineate. Odio scorrere. Inoltre, se devi scorrere una singola istruzione if , è probabile che sia troppo grande e necessiti di refactoring.
Ma; la cosa più importante di tutte è la coerenza. Usa uno o l'altro - mai entrambi!
Quando ho iniziato a programmare per la prima volta a 12 anni, ho messo le parentesi sulla riga successiva perché i tutorial di codifica di Microsoft sono fatti così. Ho anche indentato con TABS a 4 spazi quella volta.
Dopo alcuni anni ho imparato Java e JavaScript e ho visto più codice bretelle sullo stesso codice, quindi ho cambiato. Ho anche iniziato a indentare con spazi a 2 spazi.
C'è una quarta opzione che mantiene allineate le parentesi, ma non spreca spazio:
if (you.hasAnswer())
{ you.postAnswer();
i.readAnswer();
}
else
{ you.doSomething();
}
L'unico problema è che la maggior parte degli autoformattori IDE soffocano su questo.
Tutto dipende da te finché non lavori su un progetto in cui alcuni vincoli di codifica o alcuni standard sono stati impostati dal project manager che tutti i programmatori che stanno lavorando su quel progetto devono seguire durante la codifica.
Personalmente preferirei il 1o metodo.
Inoltre non ho ottenuto ciò che vuoi mostrare con il terzo metodo?
Non è un modo sbagliato? Ad esempio, considera una situazione come ..
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
Ora, se qualcuno volesse aggiungere altre dichiarazioni nel blocco if ?
In tal caso, se si utilizza il terzo metodo, il compilatore genererà l'errore di sintassi.
if (you.hasAnswer())
you.postAnswer1();
you.postAnswer2();
else
you.doSomething();
Leggi altre domande sui tag coding-style code-formatting