views:

131

answers:

2

As I'm starting to put more tracing in my code, i'm realizing it adds a lot of clutter. I know Visual Studio allows you to hide and reveal code, however, i'd like to be able group code into "tracing" code and then hide it and reveal at will as i'm reading the code. I suppose it could do this either per file or per class or per function.

Is there any way to do this? What do you guys do?

Adding some clarification

The hide current feature kind of allows you to do this except that when the code is hidden, you can't tell if its tracing or not. You also can't say "hide all tracing code" and "reveal all tracing code" which is useful when reading a function depending on what you are trying to do.

A: 

Have you considered #region?

    int x = 3;
    x++;

#region Trace
    // ...
#endregion

    x += 2;

VS will automatically allow you to expand or hide the region.

Rosarch
How would you hide all trace regions in a class or method?
Mark
Build a VS macro to hide/show matching regions would do it
CResults
Though i don't like it, i ended up using regions so i'm marking this as the answer.
Mark
+1  A: 

I'd advise against hiding it. If there's boilerplate code that's getting to the stage where it needs to be hidden away so that you can see the "real" code, then it's better to find a better way to seperate the concerns.

This is often true of tracing/debug code. Something I've looked at recently was to use a AOP framework to inject debug statements into other classes. Have a look at PostSharp, The example demonstrates how to do exactly that.

Dan
Has AOP become a widely enough used technology to become readily available and reliable? There is a lot written about it but for example it doesn't come built in the .NET framework. I'm guessing its not mature enough yet.Also, what about in method tracing (i.e. not just method entry and method exit)?
Mark
There are several libraries that let you do this sort of thing for .NET. It doesn't ship as part of the framework, but that's not necessarily a reason not to use it. I don't think that AOP is a silver bullet for this sort of thing, but I think that just "hiding" ugly code is definitely the wrong approach.
Dan
As for in method tracing, I'd argue that if your methods are long enough to require that, they're getting too long.
Dan
Are you saying you don't put tracing inside your code but only on method enter and exit?It's also not necessarily ugly code, it's tracing code. It just makes it more readable
Mark
I'm not saying never, but I certainly try to avoid it. I think it makes code less readable. It's like commenting, it gets in the way of what the program is meant to be doing. It can obviously be very useful when debugging, but if tracing code can be seperated from the code it's tracing, then I think that makes it easier to understand both of them.
Dan