Regions: Love or Hate
-
This is what I call abuse/overuse. It makes my eyes roll back in my head when I see this crap, comments would've been more than sufficient.
foreach (DataRow currentRow in sortedTable.Table.Rows) { #region Load Data and set defaults creditCardNumber = currentRow\["CCNUMBER"\].ToString(); cardHolder = currentRow\["CARDHOLDER"\].ToString(); employeeId = currentRow\["EMPLCODE"\].ToString(); deptNumber = currentRow\["DEPTCODE"\].ToString(); accountNumber = currentRow\["GLCODE"\].ToString(); expElemNumber = currentRow\["EXPELEM"\].ToString(); fullRecord = currentRow\["FULLRECORD"\].ToString(); isValidDept = true; isValidAcct = true; #endregion #region If Company Credit Card, don't process if (creditCardNumber == companyCard) { Trace.WriteLineIf(tron, "\[VERIFICATION\] Skipping Company Credit Card... "); continue; } else { this.statusReport.Text = "Verifying " + creditCardNumber + "..."; this.rtbStatus.Text += "Verifying " + creditCardNumber + " \[" + cardHolder.Trim() + "\]...\\t"; Trace.WriteLineIf(tron, "\[VERIFICATION\] Verifying Credit Card # : " + creditCardNumber); email\_er.Write("Credit Card Number: " + creditCardNumber + " for Card Holder: " + cardHolder.Trim() + "..."); } #endregion #region Address Employee #, Dept #, Account #, and Expense Element if (employeeId.Trim().Length != 4) { employeeId = employeeId.PadLeft(4, '0'); } if (deptNumber.Trim().Length != 4) { deptNumber = deptNumber.PadLeft(4, '0'); } if (accountNumber.Trim().Length != 7) { accountNumber = accountNumber.PadLeft(7, '0'); } if (expElemNumber.Trim().Length != 2) { expElemNumber = expElemNumber.PadLeft(2, '0'); } #endregion #region Verify Deptartment Number from BoA File try { isValidDept = query.isValidDepartment(deptNumber); if (!isValidDept) Trace.WriteLineIf(tron, "\[VERIFICATION\] Bank of America Department is inI think this is a good example of good usage. The advantage a region has over a comment is that a region can signal the end of your logical block. With a comment you would have to asume that the comment is valid until the next comment. And as you know, assumtion makes an ... out of u and me.
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I generally group code blocks in regions according to purpose. The file menu and edit menu each gets its own region, and printing, if the project does any printing. It helps me stay organized and makes various blocks of code easier to find.
XAlan Burkhart
-
This is what I call abuse/overuse. It makes my eyes roll back in my head when I see this crap, comments would've been more than sufficient.
foreach (DataRow currentRow in sortedTable.Table.Rows) { #region Load Data and set defaults creditCardNumber = currentRow\["CCNUMBER"\].ToString(); cardHolder = currentRow\["CARDHOLDER"\].ToString(); employeeId = currentRow\["EMPLCODE"\].ToString(); deptNumber = currentRow\["DEPTCODE"\].ToString(); accountNumber = currentRow\["GLCODE"\].ToString(); expElemNumber = currentRow\["EXPELEM"\].ToString(); fullRecord = currentRow\["FULLRECORD"\].ToString(); isValidDept = true; isValidAcct = true; #endregion #region If Company Credit Card, don't process if (creditCardNumber == companyCard) { Trace.WriteLineIf(tron, "\[VERIFICATION\] Skipping Company Credit Card... "); continue; } else { this.statusReport.Text = "Verifying " + creditCardNumber + "..."; this.rtbStatus.Text += "Verifying " + creditCardNumber + " \[" + cardHolder.Trim() + "\]...\\t"; Trace.WriteLineIf(tron, "\[VERIFICATION\] Verifying Credit Card # : " + creditCardNumber); email\_er.Write("Credit Card Number: " + creditCardNumber + " for Card Holder: " + cardHolder.Trim() + "..."); } #endregion #region Address Employee #, Dept #, Account #, and Expense Element if (employeeId.Trim().Length != 4) { employeeId = employeeId.PadLeft(4, '0'); } if (deptNumber.Trim().Length != 4) { deptNumber = deptNumber.PadLeft(4, '0'); } if (accountNumber.Trim().Length != 7) { accountNumber = accountNumber.PadLeft(7, '0'); } if (expElemNumber.Trim().Length != 2) { expElemNumber = expElemNumber.PadLeft(2, '0'); } #endregion #region Verify Deptartment Number from BoA File try { isValidDept = query.isValidDepartment(deptNumber); if (!isValidDept) Trace.WriteLineIf(tron, "\[VERIFICATION\] Bank of America Department is in -
Slacker007 wrote:
your team needs to ALL be on the same sheet of music
Oh yes! Nothing worse than one idiot individual who insists on K&R bracket format when everyone else has got an IQ bigger than their shoe size moved on to a more readable style.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
Having spent the last 10-15 minutes learning more than I ever knew, cared to know, or ever dreamed there was to know, about the names (people waste their lives inventing names for this stuff???) and histories of these various indentation styles, I now feel my brain has been eternally and irrevocably damaged for the effort. Of all the 15 minute spans of my life that have gone to waste, I believe this one will be lamented the most. And, sorry, have to agree with the last poster about your choice of styles. :)
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I find them useful to separate different regions inside a big class, like fields, properties, methods and constructors
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
I wasn't sure until I started using them to group related items in the same file: Fields Properties Constructors Event handlers Public properties Private properties Now I find it reduces the clutter, and lets you see what you are interested in, without being distracted by irrelevancies. So much so that I modified the VS default class (and so forth) files to include them as standard. There is a Tip/Trick about it here: Adding your items to Visual Studio default files[^]
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
I think this is a good example of good usage. The advantage a region has over a comment is that a region can signal the end of your logical block. With a comment you would have to asume that the comment is valid until the next comment. And as you know, assumtion makes an ... out of u and me.
That was a horrible, horrible block of code. The regions dont fix that. Logical groups should be different methods not regions. We use regions around Constants & Fields and Ctors and Dtors. And this is done automagicly by our tooling. (ReSharper + Stylecop) Other than that I cant think of anywhere else I would want to use them.
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I LOVE regions. If I really think about it though, it's more a side-effect of the regions than the regions themselves. I usually have a few main regions in my classes: private members, properties, constructors, methods, static methods etc. This has the wonderful direct effect of when I open one of my classes and I want to find property blah, I can pop open the properties region and it's there (I know I can use the drop-downs at the top of the code window but that's no fun!). It also has the, arguably, more useful side-effect of keeping all like-things together, so that when new people look at the code, it's much harder for them to put new properties at the bottom of the file instead of with the other properties. My logic here is, let's face it, most of us coders are "OCD" in the sense that we like order and symmetry and things like that, so putting a property outside of the properties region that's already defined makes you feel 'icky' and you want to move it. That's my 37 cents anyway...
Typical n-tiered architecture: DB <-> Junk(0) <-> ... <-> Junk(n-1) <-> Pretty
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I really love that feature. That said, yes they need to be used sensibly to avoid getting ugly. Regions are a great tool for organizing your code, such that when you bring up a file you are looking at a small number of regions, which - ideally - are marked so as to direct you quickly to exactly where want to go. It's a topic that a dev team needs to discuss and settle upon standard practices for, early on. IMO
James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi -
I LOVE regions. If I really think about it though, it's more a side-effect of the regions than the regions themselves. I usually have a few main regions in my classes: private members, properties, constructors, methods, static methods etc. This has the wonderful direct effect of when I open one of my classes and I want to find property blah, I can pop open the properties region and it's there (I know I can use the drop-downs at the top of the code window but that's no fun!). It also has the, arguably, more useful side-effect of keeping all like-things together, so that when new people look at the code, it's much harder for them to put new properties at the bottom of the file instead of with the other properties. My logic here is, let's face it, most of us coders are "OCD" in the sense that we like order and symmetry and things like that, so putting a property outside of the properties region that's already defined makes you feel 'icky' and you want to move it. That's my 37 cents anyway...
Typical n-tiered architecture: DB <-> Junk(0) <-> ... <-> Junk(n-1) <-> Pretty
I agree 100% - but you expressed it much better than I.
James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi -
This is what I call abuse/overuse. It makes my eyes roll back in my head when I see this crap, comments would've been more than sufficient.
foreach (DataRow currentRow in sortedTable.Table.Rows) { #region Load Data and set defaults creditCardNumber = currentRow\["CCNUMBER"\].ToString(); cardHolder = currentRow\["CARDHOLDER"\].ToString(); employeeId = currentRow\["EMPLCODE"\].ToString(); deptNumber = currentRow\["DEPTCODE"\].ToString(); accountNumber = currentRow\["GLCODE"\].ToString(); expElemNumber = currentRow\["EXPELEM"\].ToString(); fullRecord = currentRow\["FULLRECORD"\].ToString(); isValidDept = true; isValidAcct = true; #endregion #region If Company Credit Card, don't process if (creditCardNumber == companyCard) { Trace.WriteLineIf(tron, "\[VERIFICATION\] Skipping Company Credit Card... "); continue; } else { this.statusReport.Text = "Verifying " + creditCardNumber + "..."; this.rtbStatus.Text += "Verifying " + creditCardNumber + " \[" + cardHolder.Trim() + "\]...\\t"; Trace.WriteLineIf(tron, "\[VERIFICATION\] Verifying Credit Card # : " + creditCardNumber); email\_er.Write("Credit Card Number: " + creditCardNumber + " for Card Holder: " + cardHolder.Trim() + "..."); } #endregion #region Address Employee #, Dept #, Account #, and Expense Element if (employeeId.Trim().Length != 4) { employeeId = employeeId.PadLeft(4, '0'); } if (deptNumber.Trim().Length != 4) { deptNumber = deptNumber.PadLeft(4, '0'); } if (accountNumber.Trim().Length != 7) { accountNumber = accountNumber.PadLeft(7, '0'); } if (expElemNumber.Trim().Length != 2) { expElemNumber = expElemNumber.PadLeft(2, '0'); } #endregion #region Verify Deptartment Number from BoA File try { isValidDept = query.isValidDepartment(deptNumber); if (!isValidDept) Trace.WriteLineIf(tron, "\[VERIFICATION\] Bank of America Department is inI knew there was trouble in the second line of code. If a region doesn't look totally out of place in a given method, you are doing it wrong. Refactor to use another method that represents the region. Aside from that, I do personally like regions inside classes to group a few things together (such as the properties).
-
I initially thought they where a good idea, now I don't bother with them. I suppose the only place they are good for is Microsoft Generated Code from the IDE etc.
Software Kinetics Wear a hard hat it's under construction
Metro RSS -
Slacker007 wrote:
your team needs to ALL be on the same sheet of music
Oh yes! Nothing worse than one idiot individual who insists on K&R bracket format when everyone else has got an IQ bigger than their shoe size moved on to a more readable style.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
-
I see what you mean, but I don't think that way - I tend to think more from an class-centric basis, and let the class diagram and XML comments handle the external story. It's an interesting idea though!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
That is easily rectified. Hit CTRL-K, D (holding the control key between the K and the D). This will reformat code to however you have Visual Studio setup (or the default if you haven't messed with the settings).
And completely bollox up the version control...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
This is what I call abuse/overuse. It makes my eyes roll back in my head when I see this crap, comments would've been more than sufficient.
foreach (DataRow currentRow in sortedTable.Table.Rows) { #region Load Data and set defaults creditCardNumber = currentRow\["CCNUMBER"\].ToString(); cardHolder = currentRow\["CARDHOLDER"\].ToString(); employeeId = currentRow\["EMPLCODE"\].ToString(); deptNumber = currentRow\["DEPTCODE"\].ToString(); accountNumber = currentRow\["GLCODE"\].ToString(); expElemNumber = currentRow\["EXPELEM"\].ToString(); fullRecord = currentRow\["FULLRECORD"\].ToString(); isValidDept = true; isValidAcct = true; #endregion #region If Company Credit Card, don't process if (creditCardNumber == companyCard) { Trace.WriteLineIf(tron, "\[VERIFICATION\] Skipping Company Credit Card... "); continue; } else { this.statusReport.Text = "Verifying " + creditCardNumber + "..."; this.rtbStatus.Text += "Verifying " + creditCardNumber + " \[" + cardHolder.Trim() + "\]...\\t"; Trace.WriteLineIf(tron, "\[VERIFICATION\] Verifying Credit Card # : " + creditCardNumber); email\_er.Write("Credit Card Number: " + creditCardNumber + " for Card Holder: " + cardHolder.Trim() + "..."); } #endregion #region Address Employee #, Dept #, Account #, and Expense Element if (employeeId.Trim().Length != 4) { employeeId = employeeId.PadLeft(4, '0'); } if (deptNumber.Trim().Length != 4) { deptNumber = deptNumber.PadLeft(4, '0'); } if (accountNumber.Trim().Length != 7) { accountNumber = accountNumber.PadLeft(7, '0'); } if (expElemNumber.Trim().Length != 2) { expElemNumber = expElemNumber.PadLeft(2, '0'); } #endregion #region Verify Deptartment Number from BoA File try { isValidDept = query.isValidDepartment(deptNumber); if (!isValidDept) Trace.WriteLineIf(tron, "\[VERIFICATION\] Bank of America Department is inThe regions in there are completely ridiculous, but even comments couldn't have saved that code! A foreach with 150 lines including try-catches all over the place :wtf: That is just crappy coding. It should've been split up in multiple methods, with some decent naming, and then even comments would become unnecessary. A region could be used to surround all those new methods, cause that's what regions are for ;-)
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I didn't start using regions until I started at a new job. Now most of us here use them in a way that it makes sense and they aren't overused. We set up regions for the variables, constructors, functions, subs, and specific groups of sections/subs that are used for specific tasks in our code.
-
The regions in there are completely ridiculous, but even comments couldn't have saved that code! A foreach with 150 lines including try-catches all over the place :wtf: That is just crappy coding. It should've been split up in multiple methods, with some decent naming, and then even comments would become unnecessary. A region could be used to surround all those new methods, cause that's what regions are for ;-)
-
I used to love regions, stuck them everywhere in my code. Now I hate them, each member of our team uses them differently. What's the public opinion - are regions good or bad? Would they be better if they were REALLY big in Visual Studio? I find that I'm squinting to find the little buggers, if they were much more obvious I might get lost less...
I've only used regions for assignment code in blocks and for properties in classes. Now I create a separate file for properties (calling properties for ClassName something obscure like ClassNameProperties). Generally if a file gets too large to navigate through I split it up. Guess I'm still used to Hercules or smaller display drivers and small text editors on 128kB machines. Or else I just can't fit much more into my little brain. I do make good use of the XML comments. Saves a lot of time remembering what sort of perversion I wrote last week.
