I am TRWTF - compiler can't guess the keyword
-
The conversation has gone back-and-forth between
if
andswitch
. I was referring to theif
statement (I assume @accalia was as well). Not using braces withif
is very, very stupid and dumb. That's all I'm saying.
-
That's all I'm saying.
I agree, but it doesn't answer my question about braces andswitch
.
-
I have to admit, I thought it was mandatory with
switch
. In C# at least
-
@NedFodder said:
That's all I'm saying.
I agree, but it doesn't answer my question about braces andswitch
.for me it's about habits. and having coding standards that you can explain to a wet behind the ears first semester programming intern without making their head explode.
"Braces are always required" takes far less explaining than "braces for these structures are required , and optional for those structures"
and if you get into the habit of omitting braces anywhere you will eventually get bitten by some variant of
goto fail;
, so best just put them in in the first place, yeah?
-
I have to admit, I thought it was mandatory with
switch
. In C# at least
No, it's justbreak;
that's mandatory, with one exception:switch (condition) { case 1: case 2: //Do stuff break; }
-
braces and switch.
I don't think there's a reason, except to keep variables declared in each
case
separate. @Maciejasjmj seems to avoid that by declaring the variables once outside theswitch
, which seems ugly to me (variable declared too far away from where it is used). I avoid that by tying to do as little as possible in eachcase
.you will eventually get bitten by some variant of goto fail
For
if
, sure. I can't see any potential bugs happening inswitch
, though. Dammit, I'm agreeing with @loopback0!
-
For if, sure. I can't see any potential bugs happening in switch, though.
Good habits are hard to make and easy to break.
-
For
if
, sure. I can't see any potential bugs happening inswitch
, though. Dammit, I'm agreeing with @loopback0!
I've seen it happen withswitch
, but it's always been a compile-time error
-
For some reason I thought we were discussing the outer braces, and people were saying you could do
switch (condition) case 1: case 2: //Do stuff break;
Which doesn't work. I don't use braces for each case, that seems pointless to me
-
for me it's about habits. and having coding standards that you can explain to a wet behind the ears first semester programming intern without making their head explode.
"Braces are always required" takes far less explaining than "braces for these structures are required , and optional for those structures"
I'm not sure that qualifies as "necessary" but whatever.and if you get into the habit of omitting braces anywhere you will eventually get bitten by some variant of goto fail;,
No - because the habit is to specifically not use them for
switch
rather than just missing them where I feel like it.
-
-
-
I don't think there's a reason
Quite. Hence me questioning OMGZ BRACES ARE NECESSARY withswitch
.declaring the variables once outside the switch
That's where I'd declare them too.For if, sure. I can't see any potential bugs happening in switch, though.
Yup.
I don't use braces for each case, that seems pointless to me
Yup.
-
Plus, the big error was that
fail
was mis-labeled, since it didn't unconditionally cause the function to return appropriate failure outputs....Or maybe it was labeled too well, since it failed to do what it was supposed to.
-
It also allows you to reuse a name for different types of objects, but I can't think of a reason for doing that that wouldn't be
Generated code? It's easier than appending an index to each name.
-
-
-
Well, excuse me for not having come across this concept in a language that doesn't use it.
-
About a million things is how bugs get made. The braces seem unnecessary in a switch.
Yeah. That's gross and icky in Python, for whatever reason, but perfectly valid in C# as long as it's a
switch()
.... at least according to a lot of idiot programmers I've talked to.
-
Well, excuse me for not having come across this concept in a language that doesn't use it.
Use more languages.
It always kind of threw me that JavaScript didn't work that way. Very inconvenient to not be able to make a new local scope whenever you want.
-
But that's kind of my point; I've yet to come across a situation in nearly 13 years of PHP where I'd actually have found it useful to be able to do that.
-
You've spent 13 years doing PHP. It's a miracle you can speak in actual words instead of just grunts and chirps.
-
ugh ugh unnnnnnnnnnnnngh *tweet*
-
It always kind of threw me that JavaScript didn't work that way. Very inconvenient to not be able to make a new local scope whenever you want.
Sure you can. It's called a closure.
// blah blah, let's assume we're already in some local scope, there are variables defined var a = 1, b = 2; (function () { // here's a new local scope... variables from the previous scope can still be accessed // but we can safely define any new variables without worrying if the names conflict var b = 3; alert(a); // 1, because a hasn't been redefined in this scope alert(b); // 3 })(); alert(b); // still 2, because redefinition of b in the closure didn't affect it in this scope
-
-
-
Yes, because it's creating a new local scope. What part of that led you to think it wouldn't have significant overhead?
-
The block-scoped variables in ES6?
-
```
private void PoForm_Shown(object sender, EventArgs e)
{
if (db.ConnectToDatabase());
{
EnableControls(true);
lblInfo.Text = "Select PO";
}
{
lblInfo.Text = db.Error;
EnableControls(false);
}
}<abbr title="made that worse for you">MTWFY</abbr>
-
The part where new local scopes are
sub ESP, $8
in any sane language, rather than setting up a whole new activation record, trampoline, JIT-call, all that mess.
-
The part where new local scopes are sub ESP, $8 in any sane language
Why not just have no instructions for it and precompute the offsets from the frame pointer? Go ahead and inline the function expression.
-
But that's kind of my point; I've yet to come across a situation in nearly 13 years of PHP where I'd actually have found it useful to be able to do that.
I think this is just a manifestation of blub. If it's not something you think you can do, you're unlikely to spot places to use it. For instance: You might have refactored a block out to a separate function. Sometimes that's a reasonable thing to do, but having a smaller scope to work with is a different way to deal with something like that.
-
Because Javascript metaprogramming. The interpreter cannot reliably assume that a callee won't try to figure out stuff about its caller, which the spec says is the closure rather than the outer function, so it can't be elided like that.
-
Can't the interpreter assume that certain "features" of the language like the ability to replace native functions aren't used, and then take the slow path if it notices someone replacing a native function?
I'm pretty sure the default implementation of alert doesn't do any crazy stuff.
-
The block-scoped variables in ES6?
Tested that in Firefox, and it appears to run ~5% faster. Not exactly a huge difference in speed, but significant:
function test_closure() { var a = 1, b = 2; (function () { if (a != 1) throw "a is not 1 inside the closure"; var b = 3; if (b != 3) throw "b is not 3 inside the closure"; })(); if (b != 2) throw "b is not 2 in the outer scope"; } function test_let() { var a = 1, b = 2; { if (a != 1) throw "a is not 1 inside the code block"; let b = 3; if (b != 3) throw "b is not 3 inside the code block"; } if (b != 2) throw "b is not 2 in the outer scope"; } for (var k = 0; k < 5; ++ k) { var d = new Date; for (var i = 0; i < 1e6; ++ i) test_closure(); console.log(+(new Date) - d); } for (var k = 0; k < 5; ++ k) { var d = new Date; for (var i = 0; i < 1e6; ++ i) test_let(); console.log(+(new Date) - d); }
Average time for
test_closure
x 1,000,000 was 840 ms
Average time fortest_let
x 1,000,000 was 797.4 ms
-
Sure you can. It's called a closure.
New-fangled fancy-pants. I wrote JavaScript back when IE 5.5 was all the rage. I rode a horse to work and a hamburger cost a nickel.
-
Closures, new-fangled? Worked just fine in Netscape 4.5, circa 1998...
You wanna try to find a copy of IE 5.5 to test in, be my guest.
-
I'm sure it did. I never said otherwise.
-
Yes you did. You said closures were new-fangled compared to when you were writing Javascript.
-
I also said I rode a horse to work.
-
You also said you used IE 5.5 instead of Netscape. I assumed you just liked unnecessary pain and suffering.
-
Maybe we should advocate for languages to add ACBI as a standard...
Yeah, they could do it based on indentation!
-
@loopback0 said:
braces and switch.
I don't think there's a reason, except to keep variables declared in each
case
separate. @Maciejasjmj seems to avoid that by declaring the variables once outside theswitch
, which seems ugly to me (variable declared too far away from where it is used). I avoid that by tying to do as little as possible in eachcase
.I actually go for top of the function. If that's too far away semantically, the function's too large.
```
switch (condition)
case 1:
case 2:
//Do stuff
break;Which doesn't work.</blockquote> In C, it will compile, although it won't work as intended once you insert code in place of the `//Do stuff` comment.
-
-
See the link in my original rant at Channel9 when they changed it. In .NET v1.X the braces are not necessary in switch... case... blocks. This is changed since .NET v2.0
-
Firstly,
switch
is part of the C# language, not the .NET Framework.
Secondly, according to the C# 1.0 specification, braces have always been required withswitch
.
-
Humm.... Word said cannot open it because it contains corrupted text boxes.
-
Btw, seems the example in the specification does not have braces on "case" block either.
-
Word 2016 has no issues opening it, so I screenshotted the relevant part:
-
You missed the examples on the next page.
And the page you quoted just say brace is required for switch statement/block itself, not the switch sections.