#region. Sliced bread or sliced worms?

(editors note: Eric gave me several different options to use instead of sliced worms, but they were all less palatable. So to speak.)

Jeff Atwood wrote an interesting post on the use of #regions in code.

So, I thought I’d share my opinion. As somebody who’s was involved with C# development for a long time – and development in general for longer – it should be pretty easy to guess my opinion.

There will be a short intermission for you to write your answer down on a piece of paper. While you’re waiting, here are some kittens dancing…

Wasn’t that great. No relation, btw.

So, for the most part, I agree with Jeff.

The problem that I have with regions is that people seem to be enamored with their use. I was recently reviewing some code that I hadn’t seen before, and it had the exact sort of region use that Jeff describes in the Log4Net project. Before I can read through the class, I have to open them all up and look at them. In that case, regions make it significantly harder for me to understand the code.

I’m reminded of a nice post written by C# compiler dev Peter Hallam, where he talks about how much time developers spend looking at existing code. I don’t like things that make that harder.

One other reason I don’t like regions is that they give you a misleading impression about how simple and well structured your code is. The pain of navigating through a large code file is a good reason to force you to do some refactoring.

When do I like them? Well, I think that if you have some generated code in part of a class, it’s okay to put it in a region. Or, if you have a large static table, you can put it in a region. Though in both cases I’d vote to put it in a separate file.

But, of course, I’m an old dog. Do you think regions are a new trick?