Tech Off Thread

12 posts

VS2008 rule change on variable declaration?

Back to Forum: Tech Off
  • User profile image
    cheong

    This code runs without problem in VS2003:

    /*******************/
    switch (cmd)
    {
       case "A":
          string temp = "ABC";
          // use temp to do something here...
          break;
       case "B":
          string temp = "DEF";
          // use temp to do something here...
          break;
       default:
          string temp = "GHI";
          // use temp to do something here...
          break;
    }
    /*******************/

    But in VS2008, the above code will generate compile time error:
    A local variable named 'temp' is already defined in this scope.

    And I have to change like this:

    /*******************/
    string temp = null;
    switch (cmd)
    {
       case "A":
          temp = "ABC";
          // use temp to do something here...
          break;
       case "B":
          temp = "DEF";
          // use temp to do something here...
          break;
       default:
          temp = "GHI";
          // use temp to do something here...
          break;
    }
    /*******************/

    This is quite annoying to me because many of our old code use that format. The need to manually fix this one by one would certainly decrease my desire to upgrade old projects... Sad

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    gregoryw

    Adding braces for each case should solve this:

                /*******************/
                switch (cmd)
                {
                    case "A":
                        {
                            string temp = "ABC";
                            // use temp to do something here...
                            break;
                        }
                    case "B":
                        {
                            string temp = "DEF";
                            // use temp to do something here...
                            break;
                        }
                    default:
                        {
                            string temp = "GHI";
                            // use temp to do something here...
                            break;
                        }
                }
                /*******************/

  • User profile image
    littleguru

    Interesting... they made it more consistent now. Usually a scope is always between { and }. Switch was an exception of the case. They seemed to have fixed that.

  • User profile image
    littleguru

    Yeah. The migration wizard should take care of this for you. It should insert the { .... } for you and good.

  • User profile image
    cheong

    Actually it's not about editing... after all each of these "edit" are quite small, but just imagine if you need to do this for projects that have hundreds of pages and classes...

    I really want my codes to be migrated without manually modify them except in case where some classes are not supported, or behavior is changed... the amount of edit effort to migrate because of this kind of syntax difference cannot be easily justified I think...

    EDIT: Okay... I think a little scripting work will fix it... maybe I'm overreacting... I've been annoyed to those ad-hoc requests all day...

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    vesuvius

    Why are you upgrading your old projects?

    I guess it's a balancing act between availablity of new features and pain points like you're experiencing. Not sure why the compiler does not accept the old version.

    It's almost like not rewriting ArrayList boxing/deboxing into generics because it's boring and time consuming. I like elegeant code, seeing code like yours (that I had to maintain) would have me muttering horrible words about whoever wrote the initial code.

    Personally, I love new switch case semantics. Your programming is at fault though, becuase you're creating 3 temp strings instead of 1, which really is not elegant code. I would go through the process of upgrading all my switch case statements simply for elegant semantics.

    I was taught never to have duplicate code (where possible).

  • User profile image
    rcardona

    You were relying on a compiler syntax bug and now VS2008 is helping you. In some inherited code, I can't believe how much syntax slack the VB2003 compiler wasn't catching which the VB2005 compiler did. I wonder if there's more surprises in the VB2008 compiler. Looks like this is the same situation in C# or C++ above. I should extract my C# code and test it under C# 2008. I still can't move some other C++ off 2003 because of ATL changes.

  • User profile image
    evildictait​or

    rcardona wrote:
    You were relying on a compiler syntax bug and now VS2008 is helping you. In some inherited code, I can't believe how much syntax slack the VB2003 compiler wasn't catching which the VB2005 compiler did. I wonder if there's more surprises in the VB2008 compiler. Looks like this is the same situation in C# or C++ above. I should extract my C# code and test it under C# 2008. I still can't move some other C++ off 2003 because of ATL changes.


    Heh. I remember 10-15 years ago everyone was hugging PHP and Javascript etc. for their lack of types so you "didn't need all the hastle of keeping types in mind". It seems that now-a-days people are realising that types stop bugs and make code maintainable.

    It's ironic that as time progresses to make code better we are making compilers throw more of your code away and assuming less about it. But I 100% agree with the trend.

  • User profile image
    odujosh

    Yea Switch statements are evil anyways. Basically your doing a manual table look up in the example and setting temp based off the value of the switch parameter.

    I think the code would be better off if it called some data access pulled it from a source (hash table, database table, xml file, whatever) and then operate on it using a work flow. With XAML adding a branch isn't a code change. You can bring down a process push in the new XAML and bring it back up. Depending on how populaur the work flow and the eventing infrastructure you have in place you may even be able to do it in process.

    Call me a snob Smiley

  • User profile image
    Johnny​Awesome

    odujosh wrote:
    Yea Switch statements are evil anyways. Basically your doing a manual table look up in the example and setting temp based off the value of the switch parameter.

    I think the code would be better off if it called some data access pulled it from a source (hash table, database table, xml file, whatever) and then operate on it using a work flow. With XAML adding a branch isn't a code change. You can bring down a process push in the new XAML and bring it back up. Depending on how populaur the work flow and the eventing infrastructure you have in place you may even be able to do it in process.

    Call me a snob Smiley


    snob. Smiley

  • User profile image
    JoshB

    odujosh wrote:
    Yea Switch statements are evil anyways. Basically your doing a manual table look up in the example and setting temp based off the value of the switch parameter.

    I think the code would be better off if it called some data access pulled it from a source (hash table, database table, xml file, whatever) and then operate on it using a work flow. With XAML adding a branch isn't a code change. You can bring down a process push in the new XAML and bring it back up. Depending on how populaur the work flow and the eventing infrastructure you have in place you may even be able to do it in process.

    Call me a snob Smiley


    God, I'm glad you were joking!

  • User profile image
    cheong

    odujosh wrote:
    Yea Switch statements are evil anyways. Basically your doing a manual table look up in the example and setting temp based off the value of the switch parameter.

    I think the code would be better off if it called some data access pulled it from a source (hash table, database table, xml file, whatever) and then operate on it using a work flow. With XAML adding a branch isn't a code change. You can bring down a process push in the new XAML and bring it back up. Depending on how populaur the work flow and the eventing infrastructure you have in place you may even be able to do it in process.

    Call me a snob Smiley

    Actually, that's the simplified example to rule out possibility of other things. The string constants "ABC", "DEF", etc. are actually some function returning string type. I have to base commandline parameter to decide which function to call. Smiley

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.