Sollten geschweifte Klammern in einer eigenen Zeile erscheinen? [geschlossen]

Sollten geschweifte Klammern in einer eigenen Linie stehen oder nicht? Was denkst du darüber?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

oder sollte es sein

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

oder auch

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Bitte seien Sie konstruktiv! Erklären Sie, warum, tauschen Sie Erfahrungen aus und belegen Sie sie mit Fakten und Referenzen.

Als Student habe ich geschweifte Klammern in dieselbe Zeile gesetzt, damit weniger Zeilen vorhanden sind und der Code auf weniger Seiten gedruckt wird. Es ist ärgerlich, sich ein einzelnes Klammerzeichen anzusehen, das als einziges in einer Zeile gedruckt wird. (Umwelt, Papierverschwendung)

Wenn Sie jedoch große Anwendungen codieren, ist es angesichts des Gruppierungsgefühls erschwinglich, einige Zeilen nur mit geschweiften Klammern zuzulassen.

Unabhängig davon, welchen Stil Sie auswählen, sollten Sie konsistent sein, damit es für Ihr eigenes Gehirn nicht zu einem Aufwand wird, mehrere Stile in verwandten Codeteilen zu verarbeiten . In verschiedenen Szenarien (wie oben) würde ich sagen, dass es in Ordnung ist, verschiedene Stile zu verwenden. Es ist einfacher, den Kontext auf hoher Ebene zu wechseln.

Sie sollten niemals die 3. Methode durchführen.

Wenn Sie beim ersten Mal auf geschweifte Klammern verzichten, sparen Sie möglicherweise ein paar Tastatureingaben, aber der nächste Programmierer, der mitkommt, fügt Ihrer else-Klausel etwas hinzu, ohne zu bemerken, dass der Block fehlt.

Schreiben Sie Ihren Code für andere Personen.

Lange Zeit argumentierte ich, dass sie gleichwertig oder so nahe beieinander lagen, dass der mögliche Gewinn durch die Auswahl der richtigen Option weit unter den Kosten für Streitigkeiten lag .

Es ist jedoch wichtig , konsequent zu sein . Also sagte ich, lasst uns eine Münze werfen und mit dem Schreiben von Code beginnen.

Ich habe schon einmal gesehen, wie Programmierer sich solchen Veränderungen widersetzten. Komm darüber hinweg! Ich habe in meiner Karriere oft gewechselt. Ich verwende in meinem C # sogar andere Stile als in meiner PowerShell.

Vor ein paar Jahren arbeitete ich in einem Team (ca. 20 Entwickler), das entschied, Eingaben anzufordern, eine Entscheidung zu treffen und diese dann in der gesamten Codebasis durchzusetzen. Wir hätten 1 Woche Zeit, um uns zu entscheiden.

Viel Stöhnen und Augenzwinkern. Viele "Ich mag meinen Weg, weil es besser ist", aber keine Substanz.

Während wir uns mit den Feinheiten der Frage befassten, fragte jemand, wie man mit diesem Problem auf der gleichen Linie umgeht:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Beachten Sie, dass nicht sofort ersichtlich ist, wo die Parameterliste endet und der Body beginnt. Vergleichen mit:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Wir haben gelesen, wie Menschen auf der ganzen Welt mit diesem Problem umgegangen sind, und dabei das Muster gefunden, nach der offenen Klammer eine Leerzeile einzufügen:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Wenn Sie eine visuelle Pause einlegen möchten, können Sie dies auch mit einer Zahnspange tun. Dann werden auch Ihre visuellen Pausen konsistent.

Edit : Zwei Alternativen zur 'Extra Blank Line'-Lösung bei Verwendung von K & R:

1 / Die Funktionsargumente werden anders als im Funktionskörper eingerückt

2 / Setzen Sie das erste Argument in dieselbe Zeile wie den Funktionsnamen und richten Sie weitere Argumente in neuen Zeilen an diesem ersten Argument aus

Beispiele:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Bearbeiten

Ich behaupte immer noch, dass Konsistenz wichtiger ist als andere Überlegungen, aber wenn wir keinen etablierten Präzedenzfall haben , ist Klammer-an-Nächste-Linie der richtige Weg.

Die Grundregeln sind:

1. Befolgen Sie den bestehenden Kodierungsstandard des Projekts.
2. Wenn es keinen Codierungsstandard gibt und Sie eine vorhandene Codebasis bearbeiten, deren Eigentümer eine andere Person ist, sollten Sie mit dem Stil des vorhandenen Codes übereinstimmen, unabhängig davon, wie sehr Sie ihn mögen / nicht mögen.
3. Wenn Sie an einem Projekt auf der grünen Wiese arbeiten, besprechen Sie dies mit anderen Teammitgliedern und einigen Sie sich auf einen formellen oder informellen Kodierungsstandard.
4. Wenn Sie als einziger Entwickler an einem Projekt auf der grünen Wiese arbeiten, entscheiden Sie sich selbst und seien Sie dann rücksichtslos konsequent.

Auch wenn Sie keine externen Einschränkungen haben, ist es (IMO) am besten, nach einem vorhandenen (weit verbreiteten) Codierungsstandard oder einer Stilrichtlinie zu suchen und diese zu befolgen. Wenn Sie Ihren eigenen Stil rollen, besteht eine gute Chance, dass Sie es in ein paar Jahren bereuen werden.

Schließlich ist ein Stil, der mit vorhandenen Stilprüfern und Code-Formatierern implementiert / implementiert werden kann, besser als einer, der manuell "erzwungen" werden muss.

Der Vorteil der ersten Methode besteht darin, dass sie vertikal kompakter ist, sodass Sie mehr Code auf Ihrem Bildschirm anzeigen können. Deshalb bevorzuge ich sie. Das einzige Argument, das ich für die zweite Methode gehört habe, ist, dass es einfacher ist, öffnende und schließende Klammern zu koppeln, aber die meisten IDEs haben eine Tastenkombination dafür und es ist tatsächlich eine falsche Aussage - anstatt eine öffnende Klammer mit einem schließenden zu koppeln eckige Klammer Sie können eine schließende eckige Klammer mit dem Ausdruck "Blockanfang" (wenn, sonst für, während) auf derselben Einrückungsstufe koppeln, damit Sie genauso leicht feststellen können, wo der Blockanfang liegt.

Ich sehe keinen Grund, eine ganze Zeile nur für eine Klammer zu verschwenden, wenn das vorhergehende for / while / if-Konstrukt bereits den Beginn eines Blocks optisch anzeigt.

Trotzdem glaube ich, dass die schließende Klammer in einer eigenen Zeile stehen sollte, da wir etwas brauchen, um das Ende eines Blocks und seine Einrückungsstruktur auf sichtbare Weise anzuzeigen.

ich bevorzuge

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Über

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

weil die Zeile you.postAnswer();auf den ersten Blick viel leichter zu lesen und zu finden ist. Zweitens verschmilzt es mit der darüber liegenden Linie ( you.hasAnswer()), sodass meine Augen mehr fokussieren müssen, um es zu lesen.

Ich bevorzuge die erste Methode. Zahnspangen sind keine separate Linie wert.

Die Sache ist, dass Zahnspangen nicht wichtig sind. Sie sind nur syntaktischer Müll , der absolut unnötig ist, um zu verstehen, wozu Code dient, wozu er dient und wie er implementiert wird. Sie sind nur eine Hommage an alte C-ähnliche Sprachen, bei denen eine visuelle Gruppierung der Operatoren aufgrund des geringen verfügbaren Bildschirmplatzes nicht möglich war.

Es gibt Sprachen (Python, Haskell, Ruby), die ohne geschweifte Klammern überhaupt in Ordnung sind. Dies bestätigt nur, dass es sich bei geschweiften Klammern um Papierkorb handelt und dass sie nach Möglichkeit keine Zeile verdienen sollten:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Verwenden Sie Python und umgehen Sie das Argument vollständig.

Die Position der geschweiften Klammern sollte sein

Metadaten

Vom Programmierer in der IDE konfigurierbar. Auf diese Weise sehen diese lästigen Klammern im gesamten Code unabhängig vom Autor gleich aus.

Es hängt davon ab, ob.

Wenn ich in Javascript oder jQuery codiere, verwende ich das erste Formular:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Wenn ich jedoch in C # codiere, verwende ich die zweite Form, da dies die kanonische Methode ist, um dies in C # zu tun.

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; 
} 

Beachten Sie, dass Ihr Beispiel geschrieben werden kann

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

in C #.

Ich bevorzuge die erste, weil es mir schwerer fällt, den Fehler in diesem Beispiel zu erkennen.

if (value > maximum);
{
    dosomething();
}

als es in diesem Beispiel ist

if (value > maximum); {
    dosomething();
}

Das ; {sieht für mich eher falsch aus als eine Zeile, die mit endet, ;sodass ich es eher bemerke.

Ich bevorzuge eine leichte Variante von 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Warum?

• Ich denke, immer geschweifte Klammern in die eigene Zeile zu setzen, verringert die Lesbarkeit. Ich kann nur eine bestimmte Menge Quellcode auf meinem Bildschirm anzeigen. Bracket-Stil 2) macht Hove-Algorithmen mit vielen verschachtelten Schleifen und Bedingungen schmerzhaft lang.

• Ich möchte elsejedoch auf einer neuen Linie beginnen, weil ifund zusammen elsegehören, visuell. Wenn sich eine Klammer vor der befindet else, ist es viel schwieriger zu erkennen, was zu was gehört.

• 3) disqualifiziert sich. Wir alle wissen, was schlimme Dinge passieren können, wenn Sie die Klammern weglassen und es vergessen.

Ich habe irgendwo gelesen, dass die Autoren eines Buches ihren Code so formatieren wollten:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Aufgrund der Platzbeschränkungen ihres Herausgebers mussten sie jedoch Folgendes verwenden:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Jetzt weiß ich nicht, ob das stimmt (da ich es nicht mehr finde), aber der letztere Stil ist in Büchern sehr verbreitet.

Aus persönlicher Sicht bevorzuge ich die Klammern in einer separaten Zeile als:

a) Sie weisen auf einen neuen Geltungsbereich hin.
b) Es ist leichter zu erkennen, wenn Sie eine Nichtübereinstimmung haben (obwohl dies in einer IDE, die Fehler für Sie hervorhebt, weniger ein Problem darstellt).

Ah, der One True Brace Style .

Es hat alles, was für einen Heiligen Weg nötig ist - sogar einen Propheten (Richard "mein Weg oder die Autobahn" Stallman).

Der Typ hat sich in so vielen Dingen so geirrt, aber GNU ist genau richtig, wenn es um Zahnspangen geht.

[Update] Ich habe das Licht gesehen und verehre jetzt Allman

Zweites Beispiel, ich bin sehr gut in Bezug auf Lesbarkeit. Ich kann es nicht ertragen zu schauen, wenn Blöcke auf andere Weise = (

Einfache Antwort: Was ist leichter zu debuggen?

// 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 welchem ​​Fall haben Sie das Problem zuerst diagnostiziert?

Ich weiß nicht viel für den persönlichen Vorlieben (es gibt viele andere Arten, einschließlich Whitesmith und al.) Und ich kümmern sich nicht viel ... solange es nicht meine Fähigkeit nicht behindert den Code und lesen debug es.

Was das Argument "Waste Space" betrifft, kaufe ich es nicht: Ich tendiere sowieso dazu, Leerzeilen zwischen logischen Gruppen einzufügen, um das Programm klarer zu machen ...

Nicht, dass es irgendjemandem auffällt, aber aus diesem Grund gehören geschweifte Klammern in dieselbe Zeile wie die Bedingung (mit Ausnahme sehr langer Bedingungen, aber das ist ein Randfall):

In C ist dies ein gültiges Konstrukt:

while (wahr);
{
    char c;
    getchar (); // Auf Eingabe warten
}

Schnell! Was macht dieser Code? Wenn Sie mit "Endlosschleife nach Eingabe fragen" geantwortet haben, liegen Sie falsch! Es kommt nicht einmal zum Eingang. Es wird erwischt while(true). Beachten Sie das Semikolon am Ende. Dieses Muster ist tatsächlich üblicher, als es scheinen sollte; In C müssen Sie Ihre Variablen am Anfang eines Blocks deklarieren, weshalb ein neuer gestartet wurde.

Eine Codezeile ist ein Gedanke. Klammern sind ein Teil des Gedankens, der die Bedingung oder Schleife enthält. Daher gehören sie in dieselbe Linie.

Ich mag die erste Methode. Es scheint ordentlicher zu sein, und es ist kompakter, was mir gefällt.

EDIT: Ah, ein dritter. Ich mag das am besten, wenn es möglich ist, da es noch kleiner / ordentlicher ist.

Du könntest es schreiben:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Die Frage zu beantworten; Früher bevorzugte ich geschweifte Klammern in einer eigenen Zeile, aber um nicht über Fehler beim automatischen Einfügen von Semikolons in Browsern nachdenken zu müssen, begann ich mit der Verwendung des ägyptischen Stils für Javascript. Und als ich Java in Eclipse programmierte, hatte ich kein Interesse daran, den Standard-Klammerstil zu bekämpfen (oder zu konfigurieren), also habe ich mich auch in diesem Fall für Ägyptisch entschieden. Jetzt geht es mir gut mit beiden.

Fast alle Antworten hier sagen eine Variation über "Was auch immer Sie tun, bleiben Sie bei einem oder zwei".

Also habe ich einen Moment darüber nachgedacht und musste zugeben, dass ich es einfach nicht als so wichtig betrachte. Kann mir jemand ehrlich sagen, dass das Folgende schwer zu befolgen ist?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Ich bin mir über niemanden sicher ... aber ich habe absolut keine Probleme damit, mental zwischen Stilen hin und her zu wechseln. Ich brauchte ein paar Momente, um herauszufinden, was der Code tat, aber das ist das Ergebnis meiner zufälligen Eingabe von C-ähnlicher Syntax. :)

Meiner nicht ganz einfachen Meinung nach sind öffnende Klammern für die Lesbarkeit des Codes fast völlig irrelevant. Es gibt ein paar Eckfälle, in denen der eine oder andere Stil einen Unterschied macht. Zum größten Teil wird dies jedoch durch die vernünftige Verwendung von Leerzeilen behoben.

FWIW, unsere Codierungsstile bei der Arbeit verwenden eine etwas strukturiertere Form 1 und eine modifizierte Form 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

Ich bin gespannt, ob diejenigen, die Form 2 stark bevorzugen, diese Version von Form 1 besser finden, nur weil die leere Linie eine stärkere visuelle Trennung bietet.

Ich bin überrascht, dass dies noch nicht angesprochen wurde. Ich bevorzuge den zweiten Ansatz, da Sie damit den Block einfacher auswählen können.

Wenn die geschweiften Klammern in derselben Spalte und in einer eigenen Zeile beginnen und enden, können Sie am Rand oder mit dem Cursor in Spalte 0 auswählen. Dies entspricht im Allgemeinen einem großzügigeren Bereich bei der Mausauswahl oder weniger Tastenanschlägen bei der Tastaturauswahl.

Ursprünglich arbeitete ich mit geschweiften Klammern in derselben Zeile wie die Bedingung, aber als ich wechselte, stellte ich fest, dass sie die Geschwindigkeit, mit der ich arbeitete, beschleunigte. Es ist natürlich nicht Tag und Nacht, aber es ist etwas, das Sie etwas langsamer machen wird, wenn Sie mit Zahnspangen neben Ihren Konditionen arbeiten.

Ich persönlich mag den zweiten Weg.

Die Art und Weise, wie ich demonstriere, ist jedoch meiner Meinung nach die beste, weil sie die größte Arbeitsplatzsicherheit bietet! Ein Kommilitone von meiner Universität bat mich um Hilfe bei seinen Hausaufgaben und so sah sein Code aus. Das gesamte Programm sah aus wie ein einziger Block. Das Interessante ist, dass 95% der Fehler in dem von ihm erstellten Programm auf nicht übereinstimmende Klammern zurückzuführen sind. Die anderen 5% waren offensichtlich, sobald die Zahnspangen übereinstimmten.

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]='\0';
                puts(input);

Ich persönlich bevorzuge die erste Methode, wahrscheinlich, weil ich PHP auf diese Weise zum ersten Mal gelernt habe.

Für einzeilige ifAnweisungen verwende ich

if (you.hasAnswer()) you.postAnswer();

Wenn es nicht you.postAnswer();aber etwas viel länger ist, wie you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);ich wahrscheinlich auf den ersten Typ zurückgreifen werde:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Ich werde niemals einen Zeilenumbruch verwenden, und ich werde niemals diese Methode verwenden, wenn es auch eine elseAnweisung gibt.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

ist eine theoretische Möglichkeit, aber keine, die ich jemals nutzen würde. Dies müsste in verwandelt werden

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Sie sollten nicht; erste Methode für mich.

Wenn ich mir die zweite ansehe, fühlt es sich aufgrund der nicht verwendeten Zeilen (die nur geschweifte Klammern enthalten, außer der allerletzten schließenden Klammer) so an, als würde die Kontinuität des Codes durchbrochen. Ich kann es nicht so schnell lesen, weil ich besonders auf leere Zeilen achten muss, die normalerweise eine Trennung im Code oder so bedeuten, aber auf keinen Fall "diese Zeile gehört zu einer geschweiften Klammer" (die nur die Bedeutung wiederholt) Einrückung).

Genau wie beim Schreiben von Text ist das Hinzufügen von Einrückungen am Anfang eines Absatzes überflüssig, wenn sich davor eine Leerzeile befindet (doppeltes Zeichen für eine Änderung des Absatzes). In diesem Fall müssen keine Zeilen für geschweifte Klammern verschwendet werden richtig eingerückt.

Außerdem kann, wie bereits erwähnt, mehr Code in den Bildschirm eingefügt werden, was ansonsten etwas kontraproduktiv ist.

Dies hängt von der Plattform / Sprache / Konvention ab

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();
     }
}

Ich hasse es, wenn Java-Typen ihren Stil in C # -Code verwenden und umgekehrt.

Alles was ich sagen kann ist, dass wenn Sie ein Fan von Methode 3 sind, Sie von jedem IDE-Code-Formatierer auf der Erde verfolgt werden.

Ich verwende die erste Methode einfach, weil sie kompakter ist und mehr Code auf dem Bildschirm zulässt. Ich selbst hatte noch nie ein Problem mit der Paarung von geschweiften Klammern (ich schreibe sie immer zusammen mit der ifAnweisung auf, bevor ich die Bedingung hinzufüge, und in den meisten Umgebungen können Sie zur entsprechenden geschweiften Klammer springen).

Wenn Sie haben Klammern visuell paaren müssen, dann würde ich die zweite Methode bevorzugen. Dies ermöglicht jedoch weniger Code auf einmal, sodass Sie mehr scrollen müssen. Und das hat zumindest für mich eine größere Auswirkung auf das Lesen von Code als auf die korrekte Ausrichtung von geschweiften Klammern. Ich hasse Scrollen. Wenn Sie jedoch über eine einzelne ifAnweisung scrollen müssen , ist diese höchstwahrscheinlich zu groß und muss überarbeitet werden.

Aber; Das Wichtigste ist die Konsistenz. Verwenden Sie das eine oder andere - niemals beides!

Als ich mit 12 das Programmieren zum ersten Mal lernte, setzte ich die geschweiften Klammern in die nächste Zeile, da die Microsoft-Lernprogramme für die Codierung so sind. Ich habe damals auch mit 4-stelligen Tabulatoren eingerückt.

Nach ein paar Jahren lernte ich Java und JavaScript und sah mehr geschweiften Klammern im selben Code, also änderte ich mich. Ich begann auch mit 2-Leerzeichen einzurücken.

Es gibt eine vierte Option, die die Klammern ausgerichtet hält, aber keinen Platz verschwendet:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Das einzige Problem ist, dass die meisten Autoformatierer der IDE daran ersticken.

Es hängt alles von Ihnen ab, solange Sie nicht an einem Projekt arbeiten, in dem vom Projektmanager einige Codierungsbeschränkungen oder Standards festgelegt wurden, denen alle Programmierer, die an diesem Projekt arbeiten, beim Codieren folgen müssen.

Ich persönlich würde die 1. Methode vorziehen.

Ich habe auch nicht verstanden, was Sie mit der 3. Methode zeigen wollen?

Ist das nicht ein falscher Weg? Betrachten Sie zum Beispiel eine Situation als ...

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

Was ist nun, wenn jemand weitere Anweisungen im if- Block hinzufügen möchte ?

In diesem Fall löst der Compiler bei Verwendung der 3. Methode den Syntaxfehler aus.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();