[.NET] To #region or not to #region

[GrimaceODespair]

Ik heb hier al vaker intern discussie over gehad, maar ik vraag me eigenlijk af wat de meeste developers doen. Het principe van #regions lijkt heel handig om je code te structureren. Je krijg automatisch het overzicht van alle blokken code die er in je bestand staan, en je kan ze elk apart open en dicht klappen. Alleen, persoonlijk vind ik die dingen dus irritant. VS klapt ze standaard in (dat zal je vast kunnen veranderen). Als er #regions ingeklapt zijn, kan je niet zien wat voor bagger er eventueel onder schuilt. Als je bij het zoeken per ongeluk "hidden text" niet hebt aangevinkt, kan je soms zoeken tot je een ons weegt (totdat je er dus achter komt dat dat vinkje uit stond). En, komende vanuit C++, kan ik er maar gewoon niet aan wennen.

Nu dat kan allemaal volledig aan mij liggen, en daarom ben ik nieuwsgierig: Gebruiken jullie #regions in jullie C# code?

Poll: #region?
• Ja
• Nee
• Geen mening
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

[Gerco]

Meestal ben ik de enige programmeur aan een stukje code in C# (het is niet onze core business en gebeurt ook niet veel dat er in C# iets gedaan moet worden), dus van ingeklapte baggercode heb ik weinig last.

Wat ik wel handig vind is dat ik functies makkelijk kan groeperen, een region voor de property accessors (met eventueel sub regions voor bepaalde groepen). Een region voor bepaalde groepen functies etc.

Als ik in Java aan het programmeren ben, mis ik vreemd genoeg die regions helemaal niet. Hoe dat komt weet ik niet eigenlijk, misschien vanwege de outline view van Eclipse.

[MTWZZ]

Dat het standaard staat ingeklapt maakt IMHO niet zoveel uit je kunt het ook gewoon uitzetten via Tools -> Options -> Text Editor -> C# -> Advanced -> Enter outlining mode when files open. Of gewoon de sneltoets CTRL + M, CTRL + L te gebruiken.

Ik gebruik regions erg vaak zeker als je met veel gegenereerde code werkt zijn ze erg handig.

[whoami]

regions gebruik ik vaak.
Het helpt gewoon om bepaalde code snel terug te vinden. Ik zie wel vaak dat mensen regions maken zoals:

code:

#region properties

#endregion

#region Public Methods

#endregion

#region private methods

#endregion

Maar da's helemaal niet nuttig imho. Imho is het beter om je code per 'functionaliteit' te groeperen, en daar dus een region voor te maken.

En ze zijn idd handig om die gegenereerde code in een WinForm bv te 'verstoppen'.

_{op verzoek van gorgsel_19 ff een title-change gedaan, want hij voelt zich weer benadeeld omdat er C# in de titel stond, en VB.NET ook regions kent.}

[ Voor 17% gewijzigd door whoami op 13-10-2006 11:11 ]

[GrimaceODespair]

whoami schreef op vrijdag 13 oktober 2006 @ 11:10:
_{op verzoek van gorgsel_19 ff een title-change gedaan, want hij voelt zich weer benadeeld omdat er C# in de titel stond, en VB.NET ook regions kent.}

Toen ik het postte, bedacht ik mij dat dat mogelijk in VB.NET ook bestond Maar goed, wie "programmeert" er nu ook nog in die kleutertaal?

[6K]

Ik #region er ook heel wat op los
voornamelijk ook omdat het binnen de standaarden van mijn huidige opdrachtgever staat, maar daarvoor gebruikte ik ze zelf ook al.

Ook hier verdelen we onder naar private/protected/public properties/methods. Deze staan gerangschikt van public naar private.
Ik vind het wel handig

[TeeDee]

Net zoals whoami zegt doen we 'het' hier op de volgende manier:

code:

#region Properties
#region Public Methods
#region Private Methods
#region HelperMethods

Bij een webform met veel controls willen we alle controls ook nog wel eens in een region zetten:

code:

#region WebControls

Maar zoals whoami zegt is het niet nuttig en ben ik bezig om dit inderdaad op functionaliteit te groeperen. Niet dat het veel helpt want ik zie nog een shitload aan methods voorbij komen zonder een description bijvoorbeeld.

[GrimaceODespair]

TeeDee schreef op vrijdag 13 oktober 2006 @ 11:22:
Net zoals whoami zegt doen we 'het' hier op de volgende manier:

code:

#region Properties
#region Public Methods
#region Private Methods
#region HelperMethods

Bij een webform met veel controls willen we alle controls ook nog wel eens in een region zetten:

code:

#region WebControls

Maar zoals whoami zegt is het niet nuttig en ben ik bezig om dit inderdaad op functionaliteit te groeperen. Niet dat het veel helpt want ik zie nog een shitload aan methods voorbij komen zonder een description bijvoorbeeld.

Dat is eigenlijk ook een beetje mijn probleem met regions. Je kan allerlei dwarsdoorsneden van je code verzinnen om je regions in te delen, maar je loopt regelmatig tegen je eigen indeling aan. Misschien is dit ook gewoon een kwestie van ervaring, maar ik heb zelf, voordat ik stopte met regions, nooit een lekkere indeling gevonden die ik consequent kon aanhouden.

[Rigi]

Juist omdat ze inklappen vind ik ze geweldig, je moet er wel voor zorgen dat je ze goede namen geeft. Je zal ook in mijn code veel #region Properties vinden bv. Maar ook bv een Drawing region als het gaat om GUI elementen met custom uiterlijk oid.

[dotcode]

in mijn projecten laat ik region functionele delen van een classen omvatten. Een property region slaat nergens op. Verder als ik een file open ben ik geintereerd in code, dus als ik eerst 10 regions door moet lijkt mij niet echt handig

[Verwijderd]

whoami schreef op vrijdag 13 oktober 2006 @ 11:10:

En ze zijn idd handig om die gegenereerde code in een WinForm bv te 'verstoppen'.

Daar heb je toch partial classes voor?

Verder gebruik ik regions altijd als er veel tekst in komt te staan. Dan ga ik clusteren. Buttonclickjes bij elkaar, delegates apart, etc.

[whoami]

Daar heb je toch partial classes voor?

Niet in VS.NET 2003 / .NET 1.1

[Gerco]

dotcode schreef op vrijdag 13 oktober 2006 @ 11:32:
in mijn projecten laat ik region functionele delen van een classen omvatten. Een property region slaat nergens op.

Hoe doe je dat dan? Verspreid je de property accessors over je hele class om ze te groeperen bij de gerelateerde functions (voor zover mogelijk)?

Meestal staan de properties allemaal bij elkaar en wijzig ik zelden iets eraan. Om ze dan allemaal in te klappen in 1 region vind ik persoonlijk wel handig. Dan heb ik geen last van ze. "Slaat nergens op" is een sterke term die wel wat uitleg behoeft, dus steek van wal.

offtopic:
Je blog link doet het niet.

[ Voor 3% gewijzigd door Gerco op 13-10-2006 12:32 ]

[TeeDee]

dotcode schreef op vrijdag 13 oktober 2006 @ 11:32:
Verder als ik een file open ben ik geintereerd in code, dus als ik eerst 10 regions door moet lijkt mij niet echt handig

Maar om nu eerst 1000+ regels code door te bladeren om iets te vinden 'slaat nergens op'. Dan is het wel handig als het e.e.a. in een #region ingedeeld is, zodat je makkelijk kan zoeken.

[Crazy D]

Ik vind regions ook waanzinnig handig. Niet alleen om properties/functies/functionaliteit te groeperen, maar ook binnen functies om een stuk code te 'verbergen' (hoewel je dan zou kunnen zeggen, als je een stukje code dichtklapt, zou je er een aparte functie van kunnen maken, maar dat gaat niet altijd op).

Ik zit nu weer in classic asp te spelen, en als ik met VS.Net werk, vind ik regions een soort 'natuurlijk' werken, maar merk vooral hoe erg ik t mis, als ik in andere omgevingen werk....

[Mike78]

Zelf gebruik ik ze ook. Houdt het allemaal net iets overzichtelijker.

[EfBe]

Ik gebruik ook regions, maar er is wel een grens (IMHO) aan hoeveel regions je zou moeten gebruiken. Ik heb code gezien die wel 10 regions per class had en soms zelfs genest. Dan wordt het allemaal wat lastig lezen.

Met cntrl-M cntrl-M open/close je een region in de editor, dus het is niet onoverkomelijk om ze te openen/closen in de editor, maar je moet niet overdrijven. gelukkig onthoudt vs.net 2005 welke regions je open had en welke niet per file dus dat is wel een verbetering tov 2003.

Ik gebruik regions voor properties en class members, en eventueel statics /events als dat er veel zijn. Ook plaats is soms private classes die in een andere class zijn gedefinieerd in een region want het wordt anders wat lastig lezen.

Ik ben geen voorstander van het opdelen van private/public/internal methods in regions of het opdelen van groepen methods in een class per functionaliteit.

[GrimaceODespair]

EfBe schreef op vrijdag 13 oktober 2006 @ 13:10:
Ook plaats ik soms private classes die in een andere class zijn gedefinieerd in een region want het wordt anders wat lastig lezen.

Die kun je toch al inklappen zonder region? Of biedt de region hier nog een extra voordeel?

[Verwijderd]

De regions in mijn klassen zien er als volgt uit:
- #region Datamembers
- #region Properties
- #region Constants
- #region Events
- #region Delegates

Op zich een goed idee om de private-, protected- en public regions in de toekomst te gebruiken.

[L-VIS]

Ja ik denk dat de indeling vooral heel erg persoonlijk is. Zelf vind ik het handig om op webforms bijvoorbeeld events, controls en losse functies te #region-en. In data classes gebruik ze meestal als volgt:

#region private members
#region public fields
#region private methods
#region public methods

Wat mij vooral opvalt is dat als mensen de toetscombo's niet kennen, ze dit soort dingen irritant vinden. Kennen ze de juiste combo's dan vinden ze het niet zo erg.

[EfBe]

GrimaceODespair schreef op vrijdag 13 oktober 2006 @ 14:20:
[...]
Die kun je toch al inklappen zonder region? Of biedt de region hier nog een extra voordeel?

Ja per class, maar dat wordt niet opgeslagen. Ik maak een region:
#region Private Classes
// class1

// class 2
#endregion

Niet zo belangrijk, die private classes gebruik ik ook zelden (alleen in van die massive forms waarin je data met een grid moet binden via een setje objects dat je alleen in dat form gebruikt)

[GrimaceODespair]

L-VIS schreef op vrijdag 13 oktober 2006 @ 16:27:
Wat mij vooral opvalt is dat als mensen de toetscombo's niet kennen, ze dit soort dingen irritant vinden. Kennen ze de juiste combo's dan vinden ze het niet zo erg.

Misschien heb je ergens gelijk, maar ik ben zelf een sneltoetsenman die zich ergert aan mensen die dingen 5x trager doen met de muis. Dus ik denk niet dat je verhaal voor mij helemaal opgaat

[mulder]

Die dingen zouden user afhankelijk moeten zijn, het is misschien leuk als je in je eentje op een project zit, maar als je doe boel moet overdragen zit die ander zich te pleuris te zoeken.

[Verwijderd]

Afhankelijk van de afspraken in je organisatie. Hier doen we het wel.

#region Private Variables
#region Constructor(s)
#region Public Properties
#region Public Methods
#region Private Methods

Uiteraard in VB.NET dezelfde indeling. (De keuze tussen C# en VB is hier vrij, de indeling van je code niet.)

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 95% gewijzigd door Ruudjah op 01-12-2009 21:56 ]