Style question

[Christopher Benson-Manica]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

while I am steadfastly (stubbornly?) clinging to

switch(x) {
case 1:
...
case 2:
...
default:
...
}

 

[Mark A. Odell]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

while I am steadfastly (stubbornly?) clinging to

switch(x) {
case 1:
...
case 2:
...
default:
...
}

switch (cond)
{
case COND_MATCH_1:
break;

case COND_MATCH_2:
break;

default:
/* default first if the normal case and
** not the exception case.
*/
break;
}

However, I do see the appeal of the case pulled left one tab stop.

 

[E. Robert Tisdale]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

while I am steadfastly (stubbornly?) clinging to

switch(x) {
case 1:
...
case 2:
...
default:
...
}

Stubborn is right.
Just get a C code reformatter like indent:

http://www.gnu.org/software/indent/indent.html

and have it both ways.

 

[Programmer Dude]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

I agree with your boss, except the case statements themselves
should be indented 4 spaces, not 2. (And the opening brace should
be in that first column.)

 

[Richard Heathfield]

How do you indent your switch statements?

switch(expression)
{
case FIRST_CASE:
{
rc = FirstCaseCode();
break;
}
case SECOND_CASE:
{
rc = SecondCaseCode();
break;
}
case ETC:
{
rc = EtcCaseCode();
break;
}
default:
{
rc = DefaultCode();
break;
}
}

I've used function calls rather than "inline" code here, merely to make the
structure clearer. Whether I would actually use a function call would
depend on the situation.

The purpose of the extra braces is a simple one. Sometimes one wants to skip
from the top of a case to its end very quickly. Adding a brace-pair means
that editors such as vim, the VC editor, the Borland editor, and (I'll be
bound!) emacs can get from one end of the case to the other - and back -
very quickly.

 

[Christopher Benson-Manica]

How do you indent your switch statements? My boss prefers

And as a corollary, I'm trying to think of a consistent way to address
the possibility of one-line switch cases (rendered nonexistant if one
dislikes multiple returns)...

switch( val ) {
case 0: return 3;
case 1: return 2;
case 2:
/* do_stuff */
break;
default:
...
}

Are one line cases such as that suitably readable? I'll admit it, I'm
a space-saver, so I tend toward obfuscation. Or how about

switch( val ) {
case 0: a=3; break;
case 1: a=4; break;
default: a=1;
}

?

 

[CBFalconer]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

while I am steadfastly (stubbornly?) clinging to

switch(x) {
case 1:
...
case 2:
...
default:
...
}

I agree with your boss, who is obviously a person of skill and
importance. Most disagree with me and he. My argument is that
the case labels are really goto labels in disguise, and should be
easily discerned on reading. I will only indent case labels when
a nested case is in effect, i.e. I am maintaining two distinct
case indentation levels with switches. Thus the base level cases
are pulled out to the extreme left column.

To me, indentation is used to make finding the immediate
controlling statement easy, in this case the switch, where all the
decisions were made.

I will often have code snippets that look like:

switch (foo) {
case 0: bar(); break;
case 1: baz(); break;
default: punt(); break;
} /* switch */

If we are executing foo, and wonder why we got there, we just look
north and find the switch statement, unencumbered by meaningless
verbiage. For the particular case being executed, we look north
on the left hand column. All this is especially worthwhile IMO in
long complex switch statements, such as found in many state
machines.

 

[LaEisem]

How do you indent your switch statements? My boss prefers

<chop><chop>

switch (x)
{
case 1:
/* ...do stuff... */
break;

case 2:
/* ...do stuff... */
break;

default:
/* ...do stuff... */
break;
}

Indentation as shown, in increments of three spaces.
And I do mean spaces (NOT tab-characters). :>)
(On-the-job I support several old
C software packages, where
too @$#!!! spacing was done
with <ugh> tabs. I HATE tabs. :>))

 

[Bubba]

How do you indent your switch statements? My boss prefers

switch(x) {
case 1:
...
case 2:
...
default:
...
}

while I am steadfastly (stubbornly?) clinging to

switch(x) {
case 1:
...
case 2:
...
default:
...
}

Of course, in this case, the former is the correct style.
Really, this is not one of those things that makes a hell of a lot
of difference and I wouldn't risk my paycheck over it.

If you use 8 column tab stops, either a TAB is eight columns, or you use
eight spaces (lets not get into that argument) then the first method is
desirable. The first method is also K&R style. Why do K&R put the case
labels where they do? Probably because they are much like labels used for
goto and those always go clear to the left of the scope, so it seems
reasonable to put the case label clear to the left in their scope. This
being said, the second method I see quite a bit as well.

I think it is more important to maintain consistency. Unless the rest
of a system is absolutely horrendous or completely lacks some form of
style, then I would be more concerned about remaining consistent with the
rest of the code. As a general rule I find those that are too careless to
maintain consistency are unable to write good code at all.

So if you're writing code I think you should follow whatever group or
corporate standards document is provided in order to keep the code as
consistent and professional looking as possible. If you have a non
religious gripe with the coding standard then you should petition to have
it changed. I don't think something like this would qualify as
non-religious.

 

[CBFalconer]

.... snip ...

Indentation as shown, in increments of three spaces.
And I do mean spaces (NOT tab-characters). :>)
(On-the-job I support several old
C software packages, where
too @$#!!! spacing was done
with <ugh> tabs. I HATE tabs. :>))

Any decent editor will fix that for you on your first edit.

 

[Christian Bau]

Indentation as shown, in increments of three spaces.
And I do mean spaces (NOT tab-characters). :>)
(On-the-job I support several old
C software packages, where
too @$#!!! spacing was done
with <ugh> tabs. I HATE tabs. :>))

Why?

 

[Rob Thorpe]

Why?

Because people use different defaults for the number of spaces in a
tab.
Several times I have come across what looks like a badly formatted
peice of code only to find it uses a wierd number.

 

[Christopher Benson-Manica]

Any decent editor will fix that for you on your first edit.

However, certain command-line print utilities (*cough* a2ps) are
tab-unfriendly, and so I too have developed an aversion to them.

 

[Mark A. Odell]

Any decent editor will fix that for you on your first edit.

I've yet to see one handle the guy who uses space over to tab and true
tabs well. E.g.

.. = space
- = tab
first tabstop 4 second 12, third 20, etc.

int main(void)
{
...- int var;
- int foo;

.....for (var = 0; var < 12; ++var)
- {
-- foo = var * 2;
.........- foo /= 2;
-- }

....-return 0;
}

I see this all the time when I tell my editor to show spaces and tabs.

 

[Programmer Dude]

I see this all the time when I tell my editor to show spaces and
tabs.

I'll second that observation! DOWN WITH TABS!!

 

[CBFalconer]

I've yet to see one handle the guy who uses space over to tab and
true tabs well. E.g.

. = space
- = tab
first tabstop 4 second 12, third 20, etc.
.... snip ...

I see this all the time when I tell my editor to show spaces and tabs.

Vedit will handle this very nicely. Also there are various detab
filters available that do all that too. The help response from
mine:

c:\c\hashlib>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

usage: DETAB [tablist] <infile >outfile
If tablist is omitted a tab interval of 8 is assumed
If tablist has only one number, then that is the tab interval
If tablist contains multiple numbers, separated by spaces,
then they are assumed to be the tab points. The leftmost
column is numbered 0.
If tablist is a single 0, then tabs are not expanded
Backspaces in a line shut off tab expansion until cr

Any isolated lf's are converted into cr/lf pairs (Unix files)
Omitting the "<infile" causes this help screen

 

[Mark A. Odell]

Vedit will handle this very nicely. Also there are various detab
filters available that do all that too. The help response from
mine:

Vedit eh? I'll look but I *must* have a Brief keymap or my productivity
will plummet.

c:\c\hashlib>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

usage: DETAB [tablist] <infile >outfile
If tablist is omitted a tab interval of 8 is assumed
If tablist has only one number, then that is the tab interval
If tablist contains multiple numbers, separated by spaces,
then they are assumed to be the tab points. The leftmost
column is numbered 0.
If tablist is a single 0, then tabs are not expanded
Backspaces in a line shut off tab expansion until cr

How might someone get a copy of 'detab'?

Regards.

 

[Christian Bau]

Because people use different defaults for the number of spaces in a
tab.
Several times I have come across what looks like a badly formatted
peice of code only to find it uses a wierd number.

I see. Well, I hate source code that doesn't use tab = four spaces

 

[Larry Doolittle]

Why [are tabs in C source code bad]?

Because people use different defaults for the number of spaces in a
tab.
Several times I have come across what looks like a badly formatted
peice of code only to find it uses a wierd number.

I see. Well, I hate source code that doesn't use tab = four spaces

As is pointed out in the Busybox style guide, there is such a
thing as using tabs properly. If N tabs are used at the beginning
of lines that have N levels of brace nesting, they are visible as
such no matter what the tab-stop-pitch is on-screen for the current
editor (and indeed it naturally follows the preference of the reader,
not that of the author). This works most of the time. When you want
fancier alignment than can be achieved by this technique (e.g.,
lining up comments in a section of code that has multiple indentation
levels), you do indeed need to switch back to spaces instead of tabs,
and subject the reader to the tab-stop-pitch whim of the author.

- Larry

 

[CBFalconer]

.... snip ...

c:\c\hashlib>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

usage: DETAB [tablist] <infile >outfile
If tablist is omitted a tab interval of 8 is assumed
If tablist has only one number, then that is the tab interval
If tablist contains multiple numbers, separated by spaces,
then they are assumed to be the tab points. The leftmost
column is numbered 0.
If tablist is a single 0, then tabs are not expanded
Backspaces in a line shut off tab expansion until cr

How might someone get a copy of 'detab'?

Email me or otherwise supply a valid address and I'll send you the
MsDos executable. I lost my source in a crash years ago, but
never had any great urge to recreate it. If you wish to
promulgate it you have my full permission.