C# Regions... When to use them?

Paul Trippett — Thu, 28 Aug 2008 04:14:06 GMT

After reading the comments on my previous post mentioning I liked C# regions and got the general concensus is that these are very bad and evil inventions. I typed "C# Regions" into google and sure enough the first result was titled "C# Regions Considered Harmful" So my next question was why can this little handy things be considered harmful.

I have come to a conclusion and answer is over use. A lingering voice tells me this might open a horrible debate about whether they should or should not be used. End of story is that they exist we have to live with them so heres when I think they should and should not be used.

A Region should probably never be used inside a function or contain just one function - A simple comment or <summary> block will suffice. If your function seems too big maybe you should consider refactoring. A region could make sense around an interface implementation *if* your class implements more than one interface.
A Class should probably never contain just one region - Otherwise the region is simply the class (maybe you already have a comment or <summary> block on the class) so thats just duplicating information.
Place a region around your private variable declarations - this is down to your programming style, I place all my private declarations at the top of the class and 99% of the time when i open a file I am modifying a function or property so there is relly no need to see them unless I am creating something new so, for me, it makes sense to place these in a region.

Theres probably a few more maybe this list will grow over time. I am not saying use them in this way, but more if your going to use them think twice and use them wisely.

5 Things to remember when coding in a team

Paul Trippett — Mon, 25 Aug 2008 23:51:18 GMT

Whenever I tell one of my developers to do something a certain way I always get asked the question "why? doesnt it just take longer?". Well maybe it takes a little longer but Its not just because i am being a hard ass there is method behind my madness.

1. Format your code for readability:
Sure, you may understand your code inside out and know exactly what its doing but its may not always be you who has to edit the code. A few extra line breaks, proper tabbing, pretty code makes all the difference when someone else is burdened to read, understand and edit it.

2. Stick to the naming convention:
EUGHStrUPINSET, frmTest, cDataStructures, customerInformation whatever your convention, stick to it, its there so you all understand what a variable does. But IMHO dont let your naming convention be visible on public members stick to Camel Cased strings.

3. That super new functionality may be cool but...
Not everyone in your team may not understand it so whereas you maybe an ub3r l33t coder for using it. You just lost 2 days while everyone else now has to learn it. Thanks!

4. Comment it please:
It may seem straight forward but itsalways nice to know what you intended it to do just incase you wrote it with a hangover and its not doing anything slightly like what it should, if its purpose isnt commented who knows if its right or wrong.

5. Put order in your code and use #region #endregion blocks:
Why? For the meer reason I said so, I like it and it makes me happy