views:

53

answers:

2

I just noticed that when you try to generate a method stub on code where there are more { than }, the method stub gets generated incorrectly.

For instance:

    static void Main(string[] args) {
        myMethod();
    }

creating a method stub for myMethod() expands correctly into:

    static void Main(string[] args) {
        myMethod();
    }

    private static void myMethod() {
        throw new NotImplementedException();
    }

However! If I now continue and add:

{
    newMethod();

And try to generate a method stub for newMethod(), I get this:

        static void Main(string[] args) {
            myMethod();
            {
                newMethod();
        }

        private

private static void newMethod()
{
    throw new NotImplementedException();
} static void myMethod() {
            throw new NotImplementedException();
        }
    }

Can I configure Visual Studio somehow as to do it correctly? Or is this something that would have to be reported to someone?

+6  A: 

I think this is a case of garbage in, garbage out.

If your code is written in such a way that it's impossible for the auto-generation tools to tell where one code block ends and another begins then I wouldn't expect it to be able to produce meaningful results.

Dave
+1 classic GIGO
kekekela
never heard of the expression garbage in, garbage out.. Oh, you mean my code is garbage? hehe.. Well, I though it looked at the current functions, something like -- insert in between a `}` and a "`public|private return_value function_name()`" row --
Default
@Michael Only in that you're giving it a known unparsable/compilable piece of code and asking it to parse/compile it correctly.
Dave
Also, it does find it's way out into the class. It's not iterated through too many }, but still enough to exit the function I'm in (at the moment `Main`). So I do think it knows somewhat where it is.. Although, I'm just guessing..
Default
The fact remains that you can't have a mis-match in braces, that results in uncompilable code, yet according to the question you do. That there is the root cause of your problem. The auto-generation tool *may* get it right, or nearly right, given _invalid_ input, but the way to be sure it *will* get it right is to give it _valid_ input.
Dave
A: 

If you consider this behavior a bug, I recommend reporting it to Microsoft Connect.

Of course, the simple solution is to have well-formatted code prior to using code gen and automated refactor routines. I can't imagine how the text editor could "correctly" handle the potentially-unlimited variety of malformed code.

kbrimington
well, at least not insert it into another methods head :)
Default