it-swarm-eu.dev

Jsou #regiony protichůdné nebo vůně kódu?

C # umožňuje použití #region/#endregion klíčová slova, aby se oblasti kódu skryly v editoru. Kdykoli to udělám, i když to udělám, abych skryl velké kusy kódu, které by se pravděpodobně daly rozdělit do jiných tříd nebo metod. Například jsem viděl metody, které obsahují 500 řádků kódu se 3 nebo 4 regiony, jen aby byl spravovatelný.

Je tedy rozumné využívání regionů známkou potíží? Zdá se mi to.

274
Craig

Kódový zápach je příznak, který naznačuje, že v návrhu existuje problém, který potenciálně zvýší počet chyb: to není případ regionů, ale regiony mohou přispívat k vytváření kódových vůní, jako jsou dlouhé metody.

Od té doby:

Anti-vzor (nebo antipattern) je vzor používaný v sociálních nebo obchodních operacích nebo softwarovém inženýrství, který může být běžně používán, ale v praxi je neúčinný a/nebo kontraproduktivní

regiony jsou anti-vzory. Vyžadují více práce, která nezvyšuje kvalitu nebo čitelnost kódu, což nesnižuje počet chyb, a které mohou kód komplikovat pouze s refaktorem.

Nepoužívejte regiony uvnitř metod; místo toho refaktor

Metody musí být krátké . Pokud je v metodě pouze deset řádků, pravděpodobně byste nepoužívali regiony na skrytí pěti z nich, když pracujete na dalších pěti.

Každá metoda musí také dělat jednu a jednu věc . Regiony, na druhé straně, jsou určeny k oddělení různých věcí . Pokud vaše metoda dělá A, pak B, je logické vytvořit dvě oblasti, ale je to špatný přístup; místo toho byste měli metodu rozdělit do dvou samostatných metod.

Použití regionů v tomto případě může také refaktoring ztížit. Představte si, že máte:

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    if (!verification)
    {
        throw new DataCorruptedException();
    }

    Do(data);
    DoSomethingElse(data);
    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine();
    auditEngine.Submit(data);
    #endregion
}

Sbalení první oblasti, aby se soustředila na druhou, není jen riskantní: můžeme snadno zapomenout na výjimku, která zastaví tok (místo toho může existovat ochranná klauzule s return, která je ještě obtížnější najít), ale také by mělo problém, pokud by měl být kód refactored tímto způsobem:

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    var info = DoSomethingElse(data);

    if (verification)
    {
        Do(data);
    }

    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine(info);
    auditEngine.Submit(
        verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
    #endregion
}

Nyní regiony nedávají smysl a nemůžete číst a porozumět kódu ve druhé oblasti, aniž byste se dívali na kód v první oblasti.

Jiný případ, který někdy vidím, je tento:

public void DoSomething(string a, int b)
{
    #region Validation of arguments
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }
    #endregion

    #region Do real work
    ...
    #endregion
}

Je lákavé používat regiony, když validace argumentů začíná přes desítky LOC, ale existuje lepší způsob, jak tento problém vyřešit: ten, který používá zdrojový kód .NET Framework:

public void DoSomething(string a, int b)
{
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }

    InternalDoSomething(a, b);
}

private void InternalDoSomething(string a, int b)
{
    ...
}

Nepoužívejte oblasti mimo metody k seskupování

  • Někteří lidé je používají k seskupování polí, vlastností atd. Tento přístup je nesprávný: pokud je váš kód kompatibilní se stylem StyleCop, pak pole, vlastnosti, soukromé metody, konstruktéři atd. jsou již seskupeny a lze je snadno najít. Pokud tomu tak není, je čas začít uvažovat o uplatňování pravidel, která zajistí jednotnost v celé vaší kódové základně.

  • Ostatní lidé používají regiony k skrytí mnoha podobných entit . Například, pokud máte třídu se stovkami polí (což činí nejméně 500 řádků kódu, pokud spočítáte komentáře a mezeru), můžete být v pokušení umístit tato pole do oblasti, sbalit je a zapomenout na ně. Zase to děláte špatně: s tolika poli ve třídě byste měli lépe přemýšlet o použití dědičnosti nebo rozdělit objekt na několik objektů.

  • Konečně, někteří lidé jsou v pokušení používat regiony k seskupení souvisejících věcí : událost s jejím delegátem nebo metoda související s IO s jinými metodami souvisejícími s IO atd. V prvním případě se stává nepořádek, který je obtížné udržovat, číst a pochopit. Ve druhém případě by lepší návrh pravděpodobně bylo vytvořit několik tříd.

Existuje dobré využití pro regiony?

Ne. Bylo použito starší použití: generovaný kód. Nástroje pro generování kódu přesto musí místo toho použít částečné třídy. Pokud má C # podporu regionů, je to hlavně proto, že toto dědictví používá, a protože nyní, když příliš mnoho lidí používalo regiony ve svém kódu, nebylo by možné je odstranit, aniž by došlo k narušení existujících kódových bází.

Přemýšlejte o tom jako o goto. Skutečnost, že jazyk nebo funkce IDE podporuje funkci) neznamená, že by měla být používána denně. Pravidlo StyleCop SA1124 je jasné: neměli byste používat regiony nikdy.

Příklady

V současné době provádím kontrolu kódu mého spolupracovníka. Codebase obsahuje mnoho regionů a je ve skutečnosti dokonalým příkladem toho, jak regiony nepoužívat a proč regiony vedou ke špatnému kódu. Zde jsou nějaké příklady:

4 000 monster LOC:

Nedávno jsem někde četl na Programmers.SE, že když soubor obsahuje příliš mnoho usings (po vykonání příkazu „Remove Unused Usings“), je to dobré znamení, že třída uvnitř tohoto souboru dělá příliš mnoho. Totéž platí pro velikost samotného souboru.

Při kontrole kódu jsem narazil na soubor 4 000 LOC. Ukázalo se, že autor tohoto kódu stokrát jednoduše zkopíroval stejnou 15-řádkovou metodu, což mírně změnilo názvy proměnných a volanou metodu. Jednoduchý regex umožnil oříznutí souboru ze 4 000 LOC na 500 LOC, pouze přidáním několika generik; Jsem si jistý, že s chytřejším refaktoringem může být tato třída snížena na několik desítek řádků.

Použitím regionů se autor povzbuzoval, aby ignoroval skutečnost, že kód nelze udržovat a špatně psaný, a aby ho namísto jeho refaktora kód výrazně duplikoval.

Region „Do A“, Region „Do B“:

Dalším vynikajícím příkladem byla metoda inicializace monster, která jednoduše provedla úkol 1, poté úkol 2, poté úkol 3 atd. Bylo pět nebo šest úkolů, které byly zcela nezávislé, z nichž každá inicializovala něco ve třídě kontejnerů. Všechny tyto úkoly byly seskupeny do jedné metody a seskupeny do regionů.

To mělo jednu výhodu:

  • Metoda byla zcela jasná, aby se pochopila při pohledu na názvy regionů. Jak již bylo řečeno, stejná metoda, jakmile bude refakturována, bude stejně jasná jako původní metoda.

Na druhé straně byly problémy:

  • Nebylo zřejmé, zda existují závislosti mezi regiony. Doufejme, že nedošlo k opakovanému použití proměnných; jinak by údržba mohla být ještě noční můrou.

  • Tuto metodu bylo téměř nemožné otestovat. Jak byste snadno věděli, zda je metoda, která dělá dvacet věcí najednou, správně?

Oblast polí, oblast vlastností, oblast konstruktérů:

Revidovaný kód také obsahoval mnoho regionů seskupujících všechna pole dohromady, všechny vlastnosti dohromady atd. To mělo zřejmý problém: růst zdrojového kódu.

Když otevřete soubor a uvidíte obrovský seznam polí, jste více nakloněni prvnímu refaktorování třídy, pak práci s kódem. U regionů si zvyknete na kolaps věcí a zapomínáte na to.

Dalším problémem je, že pokud to uděláte všude, ocitnete se v vytváření bloků s jedním blokem, což nedává žádný smysl. To byl vlastně případ kódu, který jsem přezkoumal, kde bylo spousta #region Constructor obsahující jeden konstruktor.

A konečně, pole, vlastnosti, konstruktéry atd. měla by být již v pořádk . Pokud jsou a shodují se s konvencemi (konstanty začínající velkým písmenem atd.), Je již jasné, kde se u typu prvků zastaví a začnou jiné, takže k tomu nemusíte explicitně vytvářet regiony.

291

Je neuvěřitelné, kolik lidí nenávidí regiony tak vášnivě!

Plně souhlasím s tolika jejich námitkami: Vhození kódu do #region skrýt před pohledem je špatná věc. Rozdělení třídy na #regions, kdy by mělo být refactored do samostatných tříd je zjevně chyba. Používat #region vložit redundantní sémantické informace je, no, nadbytečné.

Ale žádná z těchto věcí neznamená, že je něco neodmyslitelně špatně s použitím regionů ve vašem kódu! Mohu jen předpokládat, že námitky většiny lidí přicházejí z práce v týmech, kde jiní mají sklon používat funkce IDE= jako jsou tyto) nesprávně. Mám luxus práce primárně sám a oceňuji způsob, jakým regiony pomohly zorganizovat můj pracovní postup. Možná je to moje obsedantně kompulzivní porucha, ale nerad vidím na obrazovce spoustu kódu najednou, bez ohledu na to, jak elegantně a elegantně to může být. do logických oblastí mi umožňuje sbalit kód, o který se já nestarám , pracovat na kódu, který jsem starám se o . Neignoruji špatně napsaný kód, nedává smysl jeho opakování více, než je, a další „meta“ organizace je spíše popisná než zbytečné.

Teď, když jsem strávil více času prací v C++, programováním příměji na rozhraní Windows API, zjistil jsem, že si přeji, aby podpora regionů byla stejně dobrá jako pro C #. Dalo by se argumentovat, že použití alternativní knihovny GUI by můj kód zjednodušilo nebo zřetelnější, čímž by se eliminovala potřeba zbavit se nepodstatného šumu kódu z obrazovky, ale mám jiné důvody, proč bych to nechtěl. S klávesnicí jsem dostatečně zdatný a IDE), že rozšíření/zhroucení kódu rozčleněného na regiony zabere méně než zlomek sekundy. Čas, který ušetřím v mozku, se snažím omezit své vědomé zaměření pouze kód, na kterém v současné době pracuji, je víc než to, co stojí za to. Všechno patří do jedné třídy/souboru, ale to vše nepatří na moji obrazovku současně.

Jde o to, že pomocí #regions oddělit a logicky rozdělit kód není špatnou věcí, které je třeba se za každou cenu vyhnout. Jak zdůrazňuje Ed, nejde o „vůni kódu“. Pokud váš kód voní, můžete si být jisti, že nepochází z regionů, ale z jakéhokoli kódu, který jste se v těchto regionech pokusili pochovat. Pokud funkce pomáhá lépe organizovat, nebo psát lepší kód, řeknu použijte. Pokud se z toho stane překážka, nebo zjistíte, že používáte nesprávně, pak stop pomocí. Pokud nejhorší dojde k nejhoršímu a vy jste nuceni pracovat v týmu s lidmi, kteří jej používají, zapamatujte si klávesovou zkratku a vypněte zvýraznění kódu: Ctrl+MCtrl+P. A přestaň si stěžovat. Někdy mám pocit, že je to další způsob, jak ti, kteří chtějí být viděni jako „pravdiví“, „hardcore“ programátoři, rádi zkoušejí a dokáží se. Nejste lepší se vyhýbat regionům než vyhýbat se syntaktickému zbarvení. Neznamená to pro vás více macho vývojáře.

Vše, co bylo řečeno, jsou regiony uvnitř metody pouhé nesmysly. Kdykoli zjistíte, že to chcete udělat, měli byste se přehodnotit do samostatné metody. Žádné výmluvy.

115
Cody Gray

Za prvé, už nemůžu vydržet termín „vůně kódu“. Používá se příliš často a většinu času se to týká lidí, kteří nedokážou rozpoznat dobrý kód, pokud je to kousne. Jakkoliv...

Osobně nemám rád mnoho oblastí. Je to těžší se dostat na kód, a kód je to, co mě zajímá. Mám rád regiony, když mám velký kus kódu, který není třeba se často dotýkat. Kromě toho se mi zdá, že se dostanou do cesty, a regiony jako „soukromé metody“, „veřejné metody“ atd. Mě jen šílují. Připomínají připomínky odrůdy i++ //increment i.

Chtěl bych také dodat, že použití regionů nemůže být ve skutečnosti „anti-vzorem“, protože tento termín se běžně používá k popisu programové logiky/návrhových vzorů, nikoli k rozvržení textového editoru. To je subjektivní; používat to, co pro vás funguje. Nikdy nebudete skončit s neudržitelným programem kvůli nadměrnému využívání regionů, o čem jsou všechny anti-vzory. :)

70
Ed S.

Ano oblasti jsou vůně kódu!

Byl bych rád, kdybych viděl regiony úplně odstraněné z kompilátoru. Každý vývojář přichází se svým vlastním zbytečným plánem péče, který nikdy nebude mít hodnotu pro jiného programátora. Mám co do činění s programátory, kteří chtějí ozdobit a zkrášlit své dítě, nic společného se skutečnou hodnotou.

Dokážete si vzpomenout na jeden příklad, kde byste „geez, přál bych si, aby můj kolega zde použil některé regiony!“?

I když mohu nakonfigurovat svůj IDE) tak, aby automaticky rozšiřoval všechny regiony, jsou stále očními bolestmi a brání čtení skutečného kódu.

Opravdu by mě to zajímalo, kdyby všechny mé veřejné metody byly seskupeny dohromady nebo ne. Gratulujeme, že znáte rozdíl mezi deklarací proměnné a inicializací, není třeba ji zobrazovat v kódu!

Bezcenný péče!

Pokud váš soubor potřebuje a „informační architekturu“ pomocí regionů, možná budete chtít bojovat s hlavním problémem: Vaše třída je příliš velká! Rozdělení na menší části je mnohem výhodnější a při správném provedení přidává skutečnou sémantiku/čitelnost.

23
Joppe

Osobně používám regiony jako způsob, jak seskupit různé typy metod nebo části kódu dohromady.

Soubor s kódem by tedy mohl vypadat takto při jeho otevření:

  • Veřejné vlastnosti
  • Konstruktory
  • Uložit metody
  • Metody úprav
  • Metody soukromého pomocníka

Nevkládám oblasti do metod. IMHO, to je známka vůně kódu. Jednou jsem narazil na metodu, která byla přes 1200 linek dlouhá a měla v ní 5 různých regionů. Byl to děsivý pohled!

Pokud jej používáte jako způsob, jak uspořádat kód takovým způsobem, který zrychlí hledání věcí pro ostatní devs, nemyslím si, že je to známka problémů. Pokud jej používáte ke skrytí řádků kódu uvnitř metody, řekl bych, že je čas přehodnotit tuto metodu.

15
Tyanna

Použití bloků #region K vytvoření velmi čitelné třídy je obvykle známkou porušení zásady jednotné odpovědnosti. Pokud jsou zvyklí na skupinové chování, pak je to také pravděpodobné, že třída dělá příliš mnoho (opět porušuje SRP).

Bloky #region, Které se drží myšlenkové linie „vůně kódu“, nejsou samy o sobě vůní kódu, ale místo toho jsou spíše „Febreze pro kód“ v tom, že se snaží skrývat pachy. I když jsem je v minulosti použil tunu, když začnete refactoring, začnete vidět méně, protože se nakonec příliš neskrývají.

10
Austin Salonen

Klíčové slovo je zde „rozumné“. Je těžké si představit případ, kdy by umístění regionu do metody bylo rozumné; to je až příliš pravděpodobné, že to bude úkryt a lenost. Mohou však existovat dobré důvody pro to, aby tu a tam bylo několik kódů.

Pokud existuje spousta a spousta regionů, myslím, že je to vůně kódu. Regiony jsou často náznakem možného místa pro budoucí refaktoring. Spousta regionů znamená, že někdo ve skutečnosti nenasvědčuje.

Používají se uvážlivě a dávají dobrý střed mezi strukturou jedné třídy s mnoha metodami a strukturou mnoha tříd s několika metodami v každé. Jsou nejužitečnější, když se třída začíná přibližovat k bodu, kdy by se měla znovu refaktorizovat do více tříd, ale ještě tam není. Seskupením souvisejících metod dohromady později usnadníme extrahování sady souvisejících metod do jejich vlastní třídy, pokud budou nadále růst v počtu. Např. Pokud mám třídu, která se blíží 500 řádků kódu, pak je sada metod využívajících 200 řádků kódu celkem shromážděných společně v regionu pravděpodobně dobrým kusem, který má nějakým způsobem ovlivnit - a v této oblasti se 100 řádky kódu metody mohou být také dobrým cílem.

Dalším způsobem, jak rád používám regiony, je snížit jeden z negativních účinků refactoringu velké metody: spousta malých, stručných, snadno opakovatelných metod, které čtenář musí procházet, aby se dostal k další většinou nesouvisející metodě. Region může být příjemným způsobem, jak metaenkapsulovat metodu a její pomocníky pro čtenáře, takže kdokoli, kdo pracuje s jiným aspektem třídy, je může jednoduše zhroutit a tuto část kódu rychle zrušit. To samozřejmě funguje pouze tehdy, jsou-li vaše regiony skutečně dobře organizovány a v zásadě využívány jako další způsob dokumentování kódu.

Obecně zjišťuji, že regiony mi pomáhají udržet se v pořádku, pomáhají „dokumentovat“ můj kód a pomáhají mi chytit místa, abych mohl rozhodovat mnohem dříve, než kdybych regiony nepoužíval.

5
Ethel Evans

Regiony používám hlavně pro třídy serverů CRUD k uspořádání různých typů operací. I tehdy bych bez nich rád šel.

Při rozsáhlém použití by se zvýšila červená vlajka. Hledal bych třídy, které mají příliš velkou odpovědnost.

Podle mých zkušeností je metoda se stovkami řádků kódem vůně.

4
TaylorOtwell

Moje pravidlo je: Pokud máte v souboru více než 5 regionů, je to vůně kód

Tj. Může být v pořádku vymezit pole, metody, vlastnosti a konstruktéry, ale pokud začínáte zabalit každou jinou metodu do oblasti, kde je vlastní, je něco vážně špatně

..a ano, byl jsem na mnoha projektech, kde tomu tak je, často kvůli špatným kódovacím standardům, generování kódu nebo obojí. Začíná rychle rychle přepínat všechny obrysy ve vizuálním studiu, abyste získali dobrý přehled o kódu.

4
Homde

REGIONY JEJICH POUŽITÍ

Použil jsem je osobně pro "ruční kódování" událostí rozhraní dříve pro aplikace Windows formulářů.

Ve své práci však používáme generátor kódu pro zpracování SQL a automaticky používá regiony k třídění svých metod výběru, aktualizace, mazání atd.

Takže když je často nepoužívám, jsou pro odstranění velkých kousků kódu naprosto v pořádku.

4
Ken

Pokud máte regiony V KÓDU , určitě máte problém (blokování případu vygenerovaného kódu.) Vložení regionů do kódu je v podstatě říkat „refactor this“.

Existují však i jiné případy. Ten, který přijde na mysl, že jsem udělal chvilku zpět: stůl s několika tisíci před přepočítanými položkami. Je to popis geometrie, bez chyby v tabulce nebude nikdy příležitost se na ni podívat. Jistě, mohla jsem získat data ze zdroje nebo podobně, ale to by vylučovalo použití kompilátoru, který by usnadnil čtení.

4
Loren Pechtel

Řekl bych, že se jedná o „vůni kódu“.

Anti-vzory jsou obecně základními strukturálními problémy v softwaru, zatímco regiony samy o sobě způsobují nepříjemné chování v editoru. Použití regionů není ve své podstatě špatné, ale jejich použití hodně, zejména ke skrytí kusů kódu, může znamenat, že jinde se dějí další, nezávislé a větší problémy.

3
whatsisname

Na nedávném projektu existovala metoda 1700 řádků s několika regiony. Zajímavé je, že regiony vymezily odlišné akce, které se v rámci metody prováděly. Byl jsem schopen udělat metodu refaktor -> extrakt pro každou z oblastí, aniž by to ovlivnilo funkčnost kódu.

Obecně jsou užitečné oblasti používané ke skrytí kódu desky kotle. Nedoporučoval bych používat regiony ke skrytí vlastností, polí a podobně, protože pokud jsou příliš nepraktické na to, aby se na ně při práci ve třídě dívali, je to pravděpodobně známka toho, že by třída měla být dále členěna. Ale jako tvrdé pravidlo, pokud vkládáte oblast do metody, pravděpodobně byste měli lépe extrahovat jinou metodu, která vysvětluje, co se děje, než zabalení tohoto bloku do oblasti.

3
Michael Brown

Lze regiony použít v kvalitním kódu? Pravděpodobně. Vsadím se, že v mnoha případech jsou. Moje osobní zkušenost mě však velmi podezřívá - viděl jsem regiony téměř výhradně zneužívané. Řekl bych, že jsem unavený, ale stále optimistický.

Pomocí kódu, který jsem dosud viděl, mohu zhruba rozdělit kód regionu do tří kategorií:

  • Špatně faktorovaný kód: Většina kódu, který jsem viděl, používá regiony jako faktoringový nástroj chudého člověka. Například třída, která se rozrostla do bodu, kdy má smysl ji specializovat pro různé účely, by mohla být místo toho rozdělena do samostatných oblastí, pro každý účel jednu.

  • Kód napsaný pomocí nesprávných knihoven a někdy nesprávným jazykem pro problémovou doménu Často, když programátor nepoužívá správnou sadu knihoven pro problémovou doménu, uvidíte, že se kód stává neuvěřitelně podrobným - se spoustou malých pomocných funkcí které opravdu nepatří (pravděpodobně patří do své vlastní knihovny).

  • Kód napsaný studenty nebo čerstvými absolventy. Zdá se, že některé programy a kurzy vyzývají studenty k tomu, aby využívali regiony pro nejrůznější podivné účely. Uvidíte oblasti, které posílají zdrojový kód do bodu, kde je poměr značek regionů k řádkům kódu v rozsahu 1: 5 nebo horší.

3
blueberryfields

Oblasti používám pouze pro jednu věc (alespoň nemůžu myslet na jiná místa, kde je používám): seskupit jednotkové testy pro metodu.

Obvykle mám pro každou třídu jednu testovací třídu a poté seskupuji testy jednotek pro každou metodu pomocí oblastí, které mají název metody. Nejste si jisti, zda se jedná o vůni kódu nebo cokoli jiného, ​​ale protože základní myšlenkou je, že jednotkové testy se nemusí měnit, dokud se nezlomí, protože se něco v kódu změnilo, takže je pro mě snazší najít všechny testy pro konkrétní metodu docela rychle.

Možná jsem v minulosti používal regiony k uspořádání kódu, ale nemohu si vzpomenout, kdy jsem to udělal naposledy. I přesto se držím svých regionů v jednotkových testech.

3
Anne Schuessler

Věřím, že se jedná o protislužbu a upřímně si myslím, že by měly být odstraněny. Ale pokud jste v nešťastné situaci pracovat na místě, kde jsou standardní, Visual Studio nabízí úžasný nástroj k minimalizaci částky, kterou byste chtěli zvracet pokaždé, když uvidíte region Nesnáším # regiony

Tento plugin bude maximalizovat velikost písma v regionech opravdu malé. Budou také rozšířeny, takže nebudete muset zasáhnout ctr + m + l, abyste otevřeli všechny regiony. Neopravuje tuto formu rakoviny kódu, ale činí ji únosnou.

2
DeadlyChambers

Regiony byly šikovným organizačním nápadem, ale nezohlednily některé vývojové tendence chtít přeceňovat kategorizaci všeho a obecně podle zbytečných moderních dnů OOP= praktiky ...) jsou „vůně“ , v tom smyslu, že jejich použití často znamená, že vaše třída/metoda je příliš velká a měla by být upravena, protože pravděpodobně porušujete zásady „S“ SOLID principů ... ale jako každý jiný) vůně, to nutně nutně neznamená, že se něco zhoršuje.

Regiony slouží ve funkčním kódu více účelu než objektově orientovanému kódu IMO, kde máte dlouhé funkce sekvenčních dat, které má smysl rozdělit, ale byly časy, které jsem osobně použil v c #, a téměř vždy zaměřte se na kód, na který se nemusíte/nechcete dívat. Pro mě to byly obvykle surové řetězcové konstanty SQL v kódové základně používané pro NPoco nebo jeho varianty. Pokud vám vlastně nebude záležet na tom, jak data přicházejí k vyplnění objektu POCO prostřednictvím vašeho ORM, bylo to naprosto zbytečné podívat se na ... a pokud vám to záleželo, hej, prostě rozšířte oblast a BAM! 150+ řádků složitého dotazu SQL pro vaše potěšení ze sledování.

0
Jeremy Holovacs

Používám oblasti, abych obsahoval každou kombinaci viditelnosti a typu prutu. Takže všechny soukromé funkce jdou do regionu atd.

Důvod, proč to dělám, není proto, abych mohl složit kód. Je to proto, že mám svého editora skriptovaný, abych mohl vložit, řekněme, odkaz na proxy:

#region "private_static_members"
 /// <summary>
 /// cache for LauncherProxy
 /// </summary>
private static LauncherProxy _launcherProxy;
#endregion

#region "protected_const_properties"
protected LauncherProxy LauncherProxy{
  get{
    if(_launcherProxy==null) {
      if (!God.Iam.HasProxy(LauncherProxy.NAME)) {
        God.Iam.RegisterProxy(new LauncherProxy());
      }
      _launcherProxy=God.Iam.Proxy(LauncherProxy.NAME) as LauncherProxy;
    }
    return _launcherProxy;
  }
}
#endregion

do kódu a nechte každou část úhledně zastrčit do správné oblasti.

V tomto případě by makro analyzovalo můj projekt, dalo mi seznam proxy serverů a vložilo kód pro ten, který chci. Můj kurzor se ani nepohybuje.

Na začátku učení C # jsem uvažoval o využití regionů pro udržení společné jednoty, ale to je hit a miss návrh, protože se nejedná o individuální vztah. Kdo se chce starat o člena, který používají dva regiony, nebo dokonce za těchto podmínek začne rozpadat věci.

Jediným dalším typem segregace jsou metody - rozdělím metody na příkazy, funkce a obsluhy, takže budu mít region pro veřejné, soukromé atd. Příkazy atd.

To mi dává granularitu, ale je to konzistentní, jednoznačné granularity, na kterou se mohu spolehnout.

0
Mark

Regiony jsou výrazy preprocesoru - jinými slovy se s nimi zachází jako s komentářem a kompilátor je v podstatě ignoruje. Jsou to čistě vizuální nástroje používané ve Visual Studio. Proto #region opravdu není vůně kódu, protože to prostě není kód. Kódový zápach je spíše 800 řádková metoda, která má mnoho různých povinností zabudovaných uvnitř atd. Takže pokud vidíte 10 oblastí v jedné metodě - pravděpodobně se používá ke skrytí zápachu kódu. Poté, co jsem řekl, že jsem je viděl, jak se velmi efektivně využívají k tomu, aby třída byla pro oči příjemnější a splavnější - také ve velmi dobře napsané a strukturované třídě!

0
BKSpurgeon