it-swarm-eu.dev

Jeden příkaz, pokud blok - rovnátka nebo ne?

Který je lepší/obecněji přijímaný?

Tento:

if(condition)
{
  statement;
}

Nebo:

if(condition)
  statement;

Mám sklon dávat přednost prvnímu, protože si myslím, že je snazší zjistit, co vlastně v bloku if patří, ušetří ostatním další přidávání složených závorek později (nebo vytvořením chyby zapomenutím), a tím usnadníte všechny vaše příkazy if jednotné místo některých s rovnátkama a jiné bez. Druhý je však stále syntakticky správný a rozhodně kompaktnější. Jsem zvědavý, co je ale obecně více preferováno ostatními.

59
Zann Anderson

První je lepší, protože druhý je náchylný k chybám. Řekněme například, že dočasně přidáváte komentář k ladění kódu:

if(condition) 
//      statement;
otherStatement;

Nebo rychle přidejte kód:

if(condition) 
    statement;
    otherStatement;

To je očividně špatné. Na druhou stranu se ten první občas cítí příliš podrobně. Proto raději umístím všechno na jeden řádek, pokud je dostatečně krátký a jednoduchý:

if(condition) statement;

Tím se sníží syntaktický šum, zatímco konstrukce bude vypadat, jako by dělala to, co ve skutečnosti dělá, takže je méně náchylná k chybám. Za předpokladu, že se tato syntaxe používá pouze pro velmi jednoduché, krátké podmínky a příkazy, považuji ji za dokonale čitelnou.

131
dsimcha

Vždy používám závorky, abych byl v bezpečí.

Je to v pořádku, když to píšete, ale víte, že v budoucnu někdo přijde a vloží další prohlášení, aniž by kolem něj dal závorky.

44
Neil Aitken

Dávám přednost verzi bez složených závorek , pokud je to možné.

Následující vysvětlení je zdlouhavé. Prosím mějte se mnou. Dám přesvědčivý důvod pro to, abych tento styl preferoval. Vysvětlím také, proč si myslím, že obvyklý protiargument neplatí.

(Téměř) prázdné řádky jsou odpad

Důvodem je to, že zavírací vzpěra vyžaduje další řádek kódu - a stejně tak otevírací vzpěra v závislosti na stylu.1

Je to hodně? Povrchně ne. Většina lidí nakonec do svého kódu vložila prázdné řádky, aby oddělily logicky mírně nezávislé bloky, což výrazně zlepšuje čitelnost.

Zneužívám však ztrátu vertikálního prostoru. Moderní monitory mají ve skutečnosti dostatek horizontálního prostoru. Ale vertikální místo je stále velmi, velmi omezené (pokud nepoužíváte monitor otočený kolmo, což není neobvyklé). Tento omezený vertikální prostor je problém: je všeobecně známo, že jednotlivé metody by měly být co nejkratší a že odpovídající rovnátka (nebo jiné oddělovače bloků) by neměla být větší než výška obrazovky v rozdílu, takže můžete vidět celý blok bez posouvání.

Toto je základní problém: jakmile už na obrazovce nevidíte celý blok, je obtížné pochopit.

V důsledku toho nenávidím zbytečné prázdné řádky. Kde jsou jednotlivé prázdné řádky rozhodující pro vymezení nezávislých bloků (stačí se podívat na vizuální vzhled tohoto textu), po sobě jdoucí prázdné řádky jsou v mé knize velmi špatný styl (a v moje zkušenost je obvykle známkou začínajících programátorů).

Stejně tak by měly být řádky, které jednoduše drží vzpěru a které by mohly být šetřeny. Blok s jedním příkazem, který je ohraničen závorkami, plýtvá jedním až dvěma řádky. S pouze 50 ish linky na výšku obrazovky, je to patrné.

Vynechání rovnátka možná neublíží

Existuje pouze jeden argument proti vynechání složených závorek: že někdo později přidá další příkaz do příslušného bloku a zapomene přidat závorky, čímž neúmyslně změní sémantiku kódu.

To by bylo opravdu hodně.

Ale podle mé zkušenosti to tak není. Jsem nedbalý programátor; a přesto mohu upřímně říci, že v mé desetileté programovací zkušenosti jsem ne jedno zapomněl přidat závorky, když přidávám zvláštní prohlášení do singletonového bloku.

Dokonce považuji za nepravděpodobné, že by to měla být běžná chyba: bloky jsou základní součástí programování. Rozlišení na úrovni bloků a určování rozsahu je automatický, zakořeněný mentální proces pro programátory. Mozek to prostě dělá (jinak by uvažování o programování bylo mnohem těžší). Není potřeba žádné další duševní úsilí k zapamatování umístění složených závorek: programátor si pamatuje také indent ​​nově přidaný příkaz, konec konců; takže programátor již mentálně zpracoval, že se jedná o blok.

Teď, ne říkám, že vynechání rovnátka nezpůsobuje chyby. Co říkám je, že Nemáme žádný důkaz tak či onak. Jednoduše nevím, zda způsobuje újmu.

Dokud mi někdo nebude moci ukázat tvrdá data, shromážděná z vědeckých experimentů, která prokáže, že se jedná o skutečný problém v praxi, zůstává tato teorie „ jen tak příběh “: velmi přesvědčivá hypotéza, která nikdy nebyla testovat, a to musí být ne použít jako argument.


1 Tento problém je někdy vyřešen umístěním všeho - včetně složených závorek - na stejnou linku:

if (condition)
{ do_something(); }

Věřím však, že je bezpečné říci, že většina lidí to pohrdá. Kromě toho by mělo stejné problémy jako varianta bez složených závor, takže je to nejhorší z obou světů.

27
Konrad Rudolph

Jdu s druhým. Je stručnější a méně podrobný.

Snažím se nepsat nejmenší společný jmenovatel, takže očekávám, že ostatní vývojáři vědí, jak napsat jednu z nejběžnějších struktur řídicích toků v programování dnes.

19
Steven Evers

Použil bych následující (konsenzus zde):

if (condition) {
    any_number_of_statements;
}

Také možné:

if(condition) single_compact_statement;

Není to tak dobré, zejména v jazycích podobných C/C++:

if(condition) 
    single_compact_statement;

(Žádná volba zde Python ;-)


V Perl byste použili:

$C = $A**3 if $A != $B;

nebo

$C = $A**3 unless $A == $B;

(Toto je není pseudokód ;-)

16
rubber boots

Používám metodu rovnátka - ze všech výše uvedených důvodů plus jeden další.

Sloučení kódu. Je známo, že se to stane na projektech, na kterých jsem pracoval na jednom prohlášení, pokud byly přerušeny automatickým sloučením. Děsivá věc je odsazení vypadá správně, i když je kód špatný, takže tento typ chyby je těžké najít.

Takže jdu s rovnátkami - na jejich vlastních linkách. Takto je snadnější zjistit úrovně. Ano, plýtvá nemovitostmi ve vertikální obrazovce a to je skutečná nevýhoda. Rovněž si myslím, že to stojí za to.

11
user36294

Žádné rovnátka. Pokud nějaký jiný programátor přidá do mého kódu druhé tvrzení, není to moje vina víc, než kdybych nechal někoho řídit auto a šli přes útes.

10
Covar

Tento argument jsme měli více než jednou a celkový konsenzus spočívá v tom, že se vždy používají rovnátka. Hlavní důvody jsou o čitelnosti/udržovatelnosti.

Pokud potřebujete do bloku if přidat kód, nemusíte si pamatovat/hledat závorky. Když budoucí programátoři čtou kód, jsou rovnátka vždy jednoznačná.

Na straně plus --- ReSharper automaticky přidá rovnátka pro líné programátory ve Visual Studiu a předpokládám, že existují doplňky pro jiné IDE , které to také udělají.

8
shimonyk

První syntaxi používám téměř bez výjimky. Protože nelze jej interpretovat špatně.

„Nenuťte mě myslet“ se nevztahuje pouze na uživatelská rozhraní, y'all ;-)

7
Steven A. Lowe

Já osobně dávám přednost druhé. První z nich vypadá ošklivě, trapně a plýtvá horizontálním prostorem. Hlavní problémy s druhým jsou makra a lidé, kteří upravují váš kód, se později dostanou špatně.

K tomu říkám „nepoužívejte makra“. Také říkám: „správně odsaďte svůj zatracený kód“. Vzhledem k tomu, jak každý textový editor/IDE použitý pro programování provádí odsazení automaticky, nemělo by to být tak obtížné. Při psaní kódu v Emacsu bych použil automatickou odrážku, abych zjistil, jestli jsem na předchozí řádek napsal něco špatně. Kdykoli Emacs začne srážet odsazení, obvykle vím, že jsem udělal něco špatně.

V praxi skončím podle toho, co bylo přede mnou nastaveno konvenční kódování. Ale tito mě obtěžují (a dělají mě mnohem šťastnější, když kóduji v Python a celá tato závada je pryč):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Pak

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Upřímně řečeno, dvě prohlášení v prohlášení if mě obtěžují mnohem víc než jediné prohlášení. Většinou proto, že jsou povinné závorky a stále to vypadá vtipně, pouze se dvěma tvrzeními v příkazu if.

5
jsternberg

Používám dvouřádkovou verzi bez složených závorek (2. formulář), ale ne pro úsporu místa.

Tento formulář používám, protože mi připadá čitelnější, vizuálně přitažlivější a snáze psitelný. Tento formulář používám, pouze pokud jsou tyto podmínky splněny; tj. podmínka if se musí pěkně hodit na jeden řádek a odpovídající příkaz se musí pěkně hodit na následující řádek. Pokud tomu tak není, použiji se rovnátka ke zlepšení čitelnosti.

Pokud použiji tento formulář, ujistím se, že před a za příkazem if (nebo nad komentářem, pokud je přítomen) je prázdný řádek (nebo řádek obsahující pouze rovnátka). I když to není pravidlo, které vědomě dodržuji, všiml jsem si to hned po přečtení této otázky.

Zachování prostoru na obrazovce pro mě není prioritou. Pokud bych potřeboval více místa, použil bych větší monitor. Moje obrazovka je již dostatečně velká na to, abych si přečetl vše, na co bych mohl potřebovat soustředit svou pozornost. Je nepravděpodobné, že bych se musel soustředit na tolik řádků kódu najednou, že by zabraly celou mou obrazovku. Pokud se toho tolik hnízdění děje s kusem kódu, že tomu nerozumím bez toho, že bych ho současně viděl více, musel bych zvážit, zda by logika mohla být lépe reprezentována refaktoringem.

Níže uvádíme několik příkladů, které ukazují, jak používám tuto formu příkazu if.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string Prompt;
        if (simpleCondition)
            Prompt = "simple assignment";
        else
            Prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }
4

Rovnátka. Vždy. Jsem jakousi jejich fanoušky, protože dává kódu určitou konzistenci. A také jak napsal @dsimcha - menší šance na chyby při přidávání dalších řádků kódu.

„Ošklivost“ složených závorek kolem jednoho řádku kódu je méně škodlivá než dodatečná práce, která je pravděpodobně v těchto případech s laděním nebo přidáním kódu.

3

Osobně chodím s hranatými závorkami.

Proč?

Pokud někdo přijde a potřebuje přidat kód do příkazu if, je to 100% jasné, kde je rozsah.

Udržuje konzistentní formát příkazů if bez ohledu na to, kolik příkazů v bloku existuje.

Pokud se však styl projektu má obejít, držte se ho.

2
ChrisF

Téměř vždy používám závorky, abych byl na bezpečné straně. Nicméně, pokud je obsah bloku opravdu krátký, nechám je vypnout a učinit z něj jednoplášťovou loď, jako je tato:

if (x==5) Console.WriteLine("It's a five!");
1
JohnFx

Upřednostňuji složené závorky, ale neztrácejí příliš mnoho mezery (takže čitelnější formát je v mém omezeném zorném poli). Takže to píšu pro dostatečně krátké řádky:

If (cond) { statement; }
1
hotpaw2

Obvykle používám rovnátka, ale v některých případech to tak není.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Pro mě by bylo hloupé je tam přidat. Pokud někdo přidá výraz za return, máme větší problémy než problémy s určováním rozsahu.

Pokud je k dispozici formátování IDE), nepoužívám rovnátka.

Na druhou stranu, pokud lze kód editovat v jiných editorech, které nepodporují automatické formátování, je nebezpečné neuvazovat závorky, jak je uvedeno v jiných příspěvcích. Ale i tak raději nepoužívám rovnátka a pro mě to nebyl problém.

0
nimcap