Change stupid indent style

[sockman]

Visual Studio (2005) automatically indents braces for each case in switch statements in what I consider to be the most impossibly idiotic manner. I have always ignored it and fixed it manually but now I'm sick of it and want to know if anyone knows of a way of changing this behaviour - I can't find any options in the formatting area.

[Mike Harnad]

VS 2008 has an option to disable "Indent braces" under Tools/Options/Text Editor/C++/Formatting. I don't remember if 2005 has the equivalent.

[sockman]

Thanks Mike. Yes 2005 has that option - I have it unchecked, but it doesn't seem to govern the bracing in switches.

I just don't know where VS got this indent style from and why it only applies it to switches. I've tried to learn to live with it and get used to it. I figured that after a while I would grow to love this style and wonder why I ever did it differently. But I can't. It's just too stupid.

[hoxsiew]

The fact that "case" and "break" in a switch statement have no requirement for being delimited by curly braces makes formatting a switch statement somewhat suggestive, but I'm curious what it is you find so annoying about VS's handling of this. How do you format your switch statements? VS's handling is consistent with they way I've always done it (since years before MS even thought of VS).

[sockman]

There are times where bracing in case branches is necessary such as the following. Case 1 is how I like to format my braces. Case 2 is how Visual studio lays it out. I find the second way much harder to read.

void MyApp::Command(int id, void* pData) 
{
   switch (id) {

      // the way I format it 

      case MSGID_SOMETHING: {
         MyObj* pObj = (MyObj*) pData;
         SomeFunc(pObj);
         break;
      }

      // the way VS formats it

      case MSGID_SOMETHINGELSE: {
         MyObj* pObj = (MyObj*) pData;
         SomeOtherFunc(pObj);
         break;
                                }
   }
}

[hoxsiew]

Indeed. I don't recall the last time I ever used braces in a case before.

[srelu]

Maybe I'll amaze you, but I think the VS uses the braces I the right way. The way you use them looks to me very confusing, althoug I have to admit many people do the same.

Your second case looks indeed very ugly, but it's your fault, not the VS's fault. You don't understand a simple fact, the braces are vertically alligned. Try to move the first brace to the next line and everything will turn to look very nice:

 
      case MSGID_SOMETHING:
      {
         MyObj* pObj = (MyObj*) pData;
         SomeFunc(pObj);
         break;
      }

To me it's crystal clear where the braces open, where they close, and which brace is the pair of the other. Don't you think the same ?

[Chris_F]

Maybe I'll amaze you, but I think the VS uses the braces I the right way. The way you use them looks to me very confusing, althoug I have to admit many people do the same.

Your second case looks indeed very ugly, but it's your fault, not the VS's fault. You don't understand a simple fact, the braces are vertically alligned. Try to move the first brace to the next line and everything will turn to look very nice:

 
      case MSGID_SOMETHING:
      {
         MyObj* pObj = (MyObj*) pData;
         SomeFunc(pObj);
         break;
      }

To me it's crystal clear where the braces open, where they close, and which brace is the pair of the other. Don't you think the same ?

I see a lot of

void foo(){

}

in GNU applications. This format has always bothered me. I guess they think saving one line is better than having braces match up.

[GeoRanger]

...I'm sick of it and want to know if anyone knows of a way of changing this behaviour...

It should cease if in Tools -> Options, Text Editor -> C/C++ -> Tabs, you set "Indenting" to "None", but you'll probably end up puting this back to it's current setting when you see what else you lose.

Can I pitch in on the rest of the discussion?

[soapbox]
Mandated coding standards are a pet peeve to which I'm signficantly opposed.

Everyone has an opinion which is no less valid than that of those around him or her. The mistake, IMO, is in deciding that writing code is not partly an artform and that one opinion is to be exalted above all others. Why would someone encourage their mind to be so inflexible as to be unable to read code unless it is has a particular format? We are humans, not the machines we program.

Some of the older code where I work has three to four different coding styles within the same file, depending on the tastes of the person who was working in it at any particular time. It's not a problem once you choose to not be bothered by it.
[/soapbox]

[Igor Vartanov]

In fact, I don't see any reason for such a buzz around the brace style. Some people consider something ugly while the others love that same much. Some adopt coding standards where brace style is explained explicitly and very strictly, but they are apparently ready to pay for that whim. Others are quite tolerant to this style point as well as to grunting of particular teammates. Man is a creature that can stand almost any torture. If he wills, of course.

[S_M_A]

Agree here Igor. Since I'm originally a Pascal programmer (at least I think that's the reason) I preferred bracing like

void f() {
}

but things do change so now I use

voif f()
{
}

After all it's better to do it like everybody else do it since that makes reading of other peoples code easier.

Having said that I have to agree that I don't wan't my brace placed líke that in a switch. If there's reason for braces in a switch I prefer it like

switch (id)
{
   case MSGID_SOMETHING: 
   {
      ...
   }
   break;
}

[D_Drmmr]

Some of the older code where I work has three to four different coding styles within the same file, depending on the tastes of the person who was working in it at any particular time. It's not a problem once you choose to not be bothered by it.

Which is exactly why coding standards exist. The point is not that one style is better than all others in every aspect, but that mixing styles is always worse than consistently using one style (no matter which one).