Care este stilul preferat pentru declarații de decizie și declarații de acțiune unice?

În cazul limbilor care sprijină decizia și acțiunea unică fără paranteze, cum ar fi următorul exemplu:

if (var == true)
    doSomething();

Care este modul preferat de a scrie acest lucru? Ar trebui să fie utilizate paranteze întotdeauna sau ar trebui ca utilizarea lor să fie lăsată ca o preferință a dezvoltatorului individual? În plus, această practică depinde de dimensiunea blocului de cod, cum ar fi în exemplul următor:

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}
0
fr hi bn

18 răspunsuri

Preferința mea este să fie consecventă, de exemplu, dacă utilizați paranteze pe un bloc, utilizați paranteze pe tot parcursul chiar cu doar o singură instrucțiune:

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Dar dacă aveți doar o grămadă de garnituri:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

Arată mai curat (dacă nu vă deranjează numele metodelor falsificate) în acest fel, dar asta sunt doar eu.

Acest lucru se aplică și constructelor de buclă și altora similare:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

De asemenea, ar trebui să considerați că aceasta este o convenție care ar putea fi mai potrivită pentru .NET (observați că Java peepz preferă să aibă prima lor bretonă în aceeași linie ca și if).

0
adăugat

Credeți-i pe acesta cu lipsa de experiență, dar în timpul șapte ani de activitate ca maimuță de cod pe care nu l-am văzut nimeni face greseala să nu adauge brațele atunci când adaugă codul unui bloc care nu au bretele. Asta e exact timp zero .

Și înainte de a ajunge la acest lucru, nu, motivul nu era "toată lumea folosește mereu bretele".

Deci, o întrebare cinstită - chiar aș vrea să primesc răspunsuri reale în loc de doar coborâșuri: se întâmplă asta vreodată?

(Edit: Am auzit suficiente povesti de horror pentru a clarifica un pic: se întâmplă vreodată cu programatori competenți ?)

0
adăugat
Am făcut această greșeală și am găsit-o și am rezolvat atunci când altcineva a făcut această greșeală. Fie că suntem competenți, este deschis pentru discuții.
adăugat autor Jay Bazuzi, sursa

Am folosit intotdeauna paranteze in orice moment, cu exceptia cazului in care verificam o variabila pentru NULL inainte de al elibera, asa cum este necesar in C

În acest caz, mă asigur că este clar că este o singură declarație prin păstrarea totul pe o linie, după cum urmează:

if (aString) free(aString);
0
adăugat

Șeful nostru ne face să punem {} după o declarație de decizie indiferent de ce, chiar dacă este o singură declarație. Este foarte enervant să adăugați două linii suplimentare. Singura excepție este operatorii ternari.

Cred că este un lucru bun că am monitorul meu de cod în orientare portret la 1200x1600.

0
adăugat

Vă recomand

if(a==b)
{
    doSomething();
}

pentru că mi se pare mult mai ușor să o fac în față decât să încerc să-mi amintesc să adaug brațele atunci când adaug o a doua declarație în ceea ce privește condiția de succes ...

if(a==b)
    doSomething();
    doSomethingElse();

este foarte diferit față de

if(a==b)
{
    doSomething();
    doSomethingElse();
}

consultați articolul lui Joel pentru mai multe detalii

0
adăugat
Ar trebui să alergi ÎNTOTDEAUNA cu bretele într-un alt/altul. Întotdeauna întotdeauna întotdeauna.
adăugat autor 5arx, sursa

There is no right or wrong way to write the above statement. There are plenty of accepted coding styles. However, for me, I prefer keeping the coding style consist throughout the entire project. ie. If the project is using K&R style, you should use K&R.

0
adăugat

Tind să folosesc dresuri în orice moment. Puteți obține niște bug-uri subtile în care ați început cu ceva de genul:

if(something)
 DoOneThing();
else
  DoItDifferently();

și apoi decideți să adăugați o altă operație la clauza else și uitați să o înfășurați în bretele:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

AlwaysGetsCalled() will always get called, and if you're sitting there at 3am wondering why your code is behaving all strange, something like that could elude you for quite some time. For this reason alone, I always use braces.

0
adăugat

Ruby renunță frumos la o problemă în discuție. Standardul pentru un singur strat este:

do_something if (a == b)

și pentru o linie multiplă:

if (a == b)
  do_something
  do_something_else
end

Acest lucru permite afirmații concise la o singură linie, dar vă forțează să reorganizați declarația dacă treceți de la una la una cu mai multe linii.

Acest lucru nu este (încă) disponibil în Java, nici în multe alte limbi, AFAIK.

0
adăugat

Obisnuiam sa urmez linia "Foloseste coastele curse intotdeauna" ca un aparat. Cu toate acestea, mi-am modificat stilul pentru a le permite să le omit pe expresii condiționate cu o singură linie:

if(!ok)return;

Pentru orice scenariu de multistat, deși eu sunt încă de părere că arcușurile ar trebui să fie obligatorii:

if(!ok){

    do();

    that();

    thing();
}
0
adăugat
Nu sunt sigur că, deși nu mă îndoiesc că există aparate de pe StackOverflow.
adăugat autor t3rse, sursa
De ce scăderea?
adăugat autor David Thornley, sursa

Regula de aur este aceea că, atunci când lucrează într-un proiect existent, urmați acele standarde de codificare.

Când sunt acasă, am două forme.

Prima este linia unică:

if (condition) doThis();

iar al doilea este pentru mai multe linii:

if (condition) {
   doThis();
}
0
adăugat

Nu există un răspuns corect. Acesta este scopul standardelor de codare din cadrul companiei. Dacă îl puteți păstra consecvent în întreaga companie, atunci va fi ușor de citit. Îmi place personal

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

dar acesta este un război sfânt.

0
adăugat

Așa cum au menționat și alții, dacă o declarație if în două rânduri fără bretele poate duce la confuzie:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

așadar, așeză-o pe o singură linie dacă pot face acest lucru fără a suferi lizibilitate:

if (a == b) DoSomething();

iar în alte vremuri folosesc bretele.

Operatorii terestre sunt puțin diferiți. De cele mai multe ori le fac pe o singură linie:

var c = (a == b) ? DoSomething() : DoSomethingElse();

dar uneori declarațiile au imbricat apeluri funcționale sau expresii lambda care face o declarație cu o singură linie dificil de analizat vizual, așa că prefer ceva de genul:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Încă mai concis decât un bloc if/else, dar ușor de văzut ce se întâmplă.

0
adăugat

În Perl dacă faci un test simplu, cândva îl vei scrie în această formă:

do_something if condition;

do_something unless condition;

Ceea ce poate fi foarte util pentru a verifica argumentele la începutul unei subrutine.

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}
0
adăugat

Nu contează cu adevărat, atâta timp cât sunteți în concordanță cu aceasta.

Se pare că există o tendință de a cere uniformitate într-o singură declarație, adică dacă există paranteze într-o ramură, există paranteze peste tot. Standardele de codificare a kernelului Linux, pentru unul, mandatează acest lucru.

0
adăugat

eu prefer

if (cond)
   {
   //statement
   }

chiar și cu o singură declarație. Dacă aveați de gând să scrieți o singură dată, nu avea nici o îndoială că a funcționat și nu a planificat niciodată un alt coder care să se uite la codul respectiv, mergeți mai departe și folosiți formatul dorit. Dar, ce te-a costat extra bracketing-ul? Mai puțin timp pe parcursul unui an decât este necesar pentru a introduce acest post.

Da, îmi place să-mi încadrez brațele la nivelul blocului.

Python este frumos în sensul că indentația definește blocul. Întrebarea este înșelătoare într-o astfel de limbă.

0
adăugat

Aș susține cu tărie mereu utilizarea brațelor, chiar și atunci când ele sunt opționale. De ce? Luați această bucată de cod C ++:

if (var == 1)
  doSomething();
doSomethingElse();

Acum vine cineva care nu acordă suficientă atenție și decide că trebuie să se întâmple ceva în plus dacă (var == 1), așa că fac asta:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

Totul este încă frumos indentat, dar nu va face ceea ce a fost intenționat.

Folosind mereu bretele, este mai probabil să eviți acest tip de bug.

0
adăugat

Am tendința să fiu de acord cu Joel Spolsky cu privire la acel articol cu ​​acest articol ( Efectuarea de cod greșit arata greșit ) cu următorul exemplu de cod:

if (i != 0)
bar(i);
foo(i);

Foo este acum necondiționat. Care este adevărat rău!

Întotdeauna folosesc paranteze pentru declarații de decizie. Aceasta ajută la menținerea codului și face ca codul să fie mai puțin predispus la erori.

0
adăugat

Eu personal parte cu explicația lui McConnell de la Code Complete.

Folosiți-le ori de câte ori puteți. Îmbunătățește citirea codului dvs. și elimină confuziile puține și rare care ar putea apărea.

Există un lucru mai important, deși ... Consistența. Cu stilul pe care îl folosiți, asigurați-vă că faceți totdeauna același lucru.

Începeți să scrieți chestii precum:


If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

Sunteți obligat să căutați un bug ciudat unde compilatorul nu va înțelege ce încercați să faceți și că va fi greu de găsit.

În principiu, găsiți cel care vă este confortabil să scrieți tot timpul și să vă lipiți de el. Cred că folosirea delimitatorilor de blocuri ('{', '}') este calea de parcurs.

Nu vreau să încep o întrebare în interiorul altui, dar este ceva legat de acest lucru pe care vreau să-l menționez pentru a-ți lua sucul mental. A fost luată decizia de a folosi parantezele. Unde puneți consola de deschidere? Pe aceeași linie cu declarația sau dedesubt. Paranteze indentate sau nu?


If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

Nu răspundeți la acest lucru, deoarece aceasta ar fi o nouă întrebare. Dacă văd un interes în acest lucru, voi deschide o nouă întrebare.

0
adăugat