Which one, Jow Forums?

which one, Jow Forums?

Attached: Capture.png (254x370, 9K)

Neither.

>dude it doesn't matter just be consistent

Attached: soytastic.png (500x499, 45K)

The first

neither you fucktard, case gets the same indentation as switch.

The first, obviously. The only issue might be ambiguity if the person thinks that the case breaks automatically once it is selected; the second one might help a bit with that since it doesn't resemble the usual indentation you do with other control-flow constructs.

1st one

First.
There is no debate.

switch (condition) {
case 1:
doSomething();
case2:
doSomething();
// ...
}

trick question. It's neither because the opening brace actually goes on its own line.

no the fuck it doesn't

First is comfy

>4 spaces
your intendation is fucked. Tabstop should be 8.
Intend your case blocks.

>8
Disgusting

Neither, inline is the patrician choice.

This but with annotated fallthrough

switch (contidion) {
case 1:
doSomething();
break;
case 2:
doSomething();
break;
...
}

anything other is heresy.

based

Attached: 5cbf54a6761d5695457bad2ab93bec82.png (786x765, 152K)

My IQ is above 130 so...
switch(niggers)
{
case 1:
gas();
break;
case 0:
reddit();
break;
}
[\code]

match condition {
case1 => {
doSomething();
}
case 2 => {
doSomethingElse();
}
}

>gas
>stepping on the breaks immediately after
m8

disgusting

Second option.
Why?
Because in the first option you intended case to switch but not statement to case. That to me seems inconsistent.
If you're going to intent, then intend. If you're not then don't.

absolutely horrendous

this

Attached: 1551838957782.jpg (700x875, 97K)

switch (condition) {
case 1:
doSomething();
/* FALLTHROUGH */
case 2:
doSomething();
}

if/else

only correct answer thus far

Man, I can smell the curry from way over here~~ ew

if condition==1 or condition==2:
doSomething()

How about this?

Attached: fizz buzz.png (592x936, 27K)

The second option. To me case is more like a label rather than a statement, so the code within it shouldn't be a new block level. It's just there to identify where the switch should jump to in the switch block.

Attached: 1538807473769.png (817x326, 74K)

(case condition
((case1) (dosomething))
((case2) (dosomething)))

Finally, a true blue blooded Jow Forumsentleman! You sir have got taste.

Aren't switches faster than using if? Why are they faster?

Depends, if you have long sequences of them it can be implemented as a jump table which is sometimes more efficient.

switch (val){
case cond0:
blah();
break;

case cond1:
blugh();
break;
}

this is the only correct way

Kill yourself

abomination

/thread

who needs brackets and tabs...
CASE
case_1 OF code_1 ENDOF
case_2 OF code_2 ENDOF
...
case_k OF code_k ENDOF
default-code
ENDCASE

switch (
condition ){
case 1:
dostuff(); }

baste

Attached: dog_wink.jpg (655x640, 49K)

>People who barely code discussing indentation instead of design patterns to make themselves seem experienced.
Yikes, not this again...

>user took a meme software engineering course and is high on dunning kruger and ready to wave dicks with the others who went down that path on Jow Forums

Just use an auto-formatter and stop worrying about shit like that.

switch (condiition) {
case 1:
do_something();
case 2:
do_something();
}

This but without implicit fallthrough
ftfy

this

>Dunning-Kruger strikes again

Not everyone is constantly trying to impress people with how much they code, regular people can have discussions about trivial things.

neither. switch is deprecated

I prefer to be able to safely declare variables in my switch blocks and easily tell at a distance where each case begins and ends.
switch (condition) {
case value: {
statement;
...
} break; case value: {
statement;
...
} break; case value: {
statement;
...
}
...
}

nice troll

Neither.

Not a troll, I actually write switch blocks like this. What's the problem with it?

if(condition == 1) doSomething();
if(condition == 2) doSomething();

Not the user you replied to, but I have to say that among all the previous replies yours is the least idiomatic, a.k.a this is my first time seeing it done like this. Personally I'll go with something like what the OpenBSD guys use, here is an excerpt from there "cat.c" source code:
switch (ch) {
case 'b':
bflag = nflag = 1; /* -b implies -n */
break;
case 'e':
eflag = vflag = 1; /* -e implies -v */
break;
case 'n':
nflag = 1;
break;
case 's':
sflag = 1;
break;
case 't':
tflag = vflag = 1; /* -t implies -v */
break;
case 'u':
setvbuf(stdout, NULL, _IONBF, 0);
break;
case 'v':
vflag = 1;
break;
default:
(void)fprintf(stderr,
"usage: %s [-benstuv] [file ...]\n", __progname);
return 1;
}

Just use whatever the fuck is the default in your editor. The time you waste trying to configure this shit isn't worth it.

Neither, switch is for retards. Use guards and pattern matching.

That format is pretty good but you can't declare variables in it.

> That format is pretty good
It has to be. Big ass old projects thrive on cooperative work, and the last thing you want is for contributors to flee due to incomprehensible and/or ugly style. You should see how clear any one of their files is and how easily structure is conveyed to the reader.
> you can't declare variables in it
I am an old dog (have not moved from C and the occasional recreational lisp) so all my variable declarations go to the top of the current block.

>I am an old dog (have not moved from C and the occasional recreational lisp) so all my variable declarations go to the top of the current block.
Makes sense I guess. I often find myself declaring variables mid-function because I don't necessarily know I'll need them when I start writing it, I guess it would be better to move them to the top so I can see at a glance how much memory the stack frame occupies

I prefer more compact formatting...

switch(condition) {case 1: doSomething(); case2: doSomething(); ... }

fpbp

> I guess it would be better to move them to the top
I don't think my way of doing things is any better than yours. It is just that I avoid long functions, ones that go beyond a screenful I just break unless I really can't. And so variable declarations just organically and naturally end up going at the beginning of the current block which coincides more often than not with that of the function. This also helps with my mental focus, as I am not as capable of holding as much details in my head as I used to.

If you think you need to declare variables in the body of a switch you need to refactor.