Il posizionamento della parentesi influisce sulla leggibilità?

Question

Possibili duplicati:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions'/'tags' rollover buttons

public void Method { 

} 

o

public void Method 
{ 

} 

Oltre preferenze personali Quali sono i vantaggi di uno stile piuttosto che un altro? Ero solito giurare secondo il secondo metodo, anche se ora uso il primo stile per lavoro e progetti personali.

Con la leggibilità intendo immagino codice in quei metodi - if/else ecc ...

Answer 1

Penso che sia completamente soggettivo, tuttavia, penso che sia importante stabilire standard di codice per la tua squadra e far usare a tutti lo stesso stile. Detto questo, mi piace il secondo (e ho fatto usare la mia squadra) perché sembra più facile da leggere quando non è il tuo codice.

Answer 2

le vostre linee di conteggio codice sarà molto meno con la prima opzione. :)

Answer 3

Primo uno è più piccolo in termini di numero di linee (forse è per questo che lo sviluppo -Java- libri tendono ad usare quella sintassi)

secondo è, secondo me più facile da leggere come hai sempre fatto due allineati parentesi.

In ogni caso, entrambi sono ampiamente utilizzati, è una questione di preferenze personali.

Answer 4

In passato usavamo il primo stile (stile K & R) perché gli schermi erano più piccoli e il codice veniva spesso stampato su questa roba chiamata carta.

In questi giorni abbiamo un grande schermo e il secondo metodo (stile ANSI) rende più semplice vedere se le vostre parentesi corrispondono.

Vedere HERE e HERE per ulteriori informazioni.

Answer 5

Uso l'istruzione if come qualcosa su cui ragionare in questo argomento altamente emotivo.

if (cond) { 
    //code 
} 

semplicemente chiedendo che aspetto ha l'altra istruzione? L'estensione logica di quanto sopra è: -

if (cond) { 
    //code 
} else { 
    //more code 
} 

È leggibile? Io non la penso così ed è anche semplicemente brutto.

Più righe è! = Meno leggibile. Quindi andrei con la tua seconda opzione.

Answer 6

Google C++ Style Guide suggerisce

Tipo di ritorno sulla stessa riga del nome funzione, parametri sulla stessa linea se si adattano.

funzioni simile a questa:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { 
    DoSomething(); 
    ... 
} 

---

WebKit Coding Style Guidelines suggerisce

definizioni di funzione: luogo ogni bretelle sulla propria riga.

destra:

int main() 
{ 
    ... 
} 

Sbagliato:

int main() { 
    ... 
} 

Essi suggeriscono bretelle-on-stessa-line per tutto il resto, però.

---

GNU Coding Standards suggerisce

È importante mettere l'open-tutore che avvia il corpo di una funzione C nella prima colonna, in modo che essi iniziare una _defun_. Diversi strumenti cercano parentesi aperte nella prima colonna per trovare l'inizio delle funzioni C. Questi strumenti non funzioneranno su codice non formattato in questo modo.

Evitare di mettere parentesi aperta, parentesi aperta o parentesi aperta nella prima colonna quando si trovano all'interno di una funzione, in modo che non possano avviare un defun. La parentesi aperta che avvia un corpo della struct può andare nella prima colonna se ritieni utile trattare questa definizione come defun.

È inoltre importante che le definizioni di funzione avviino il nome della funzione nella prima colonna. Questo aiuta le persone a cercare definizioni di funzioni e può anche aiutare certi strumenti a riconoscerle. Così, utilizzando la sintassi standard C, il formato è questo:

static char * 
concat (char *s1, char *s2) 
{ 
    ... 
} 

o, se si desidera utilizzare la sintassi C tradizionale, formattare la definizione in questo modo:

static char * 
concat (s1, s2)  /* Name starts in column one here */ 
    char *s1, *s2; 
{      /* Open brace in column one here */ 
    ... 
} 

---

Come si può vedere, ognuno ha le proprie opinioni. Personalmente, preferisco le parentesi graffe Perl-ish-on-same-line-except-for-else, ma finché tutti coloro che lavorano sul codice possono collaborare, non importa.

Answer 7

Personalmente trovo il secondo più leggibile (curly allineato).

È sempre più facile per una squadra andare con i valori predefiniti, e dal momento che io e Visual Studio siamo d'accordo su questo, questo è il mio argomento. ;-)