missing out braces

[Andrew Bullock]

I thought the two bits of code should be the same?

They aren't evaluating the same for me ....

Can someone tell me why please?

Thanks

Andrew


if (X != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
else
if (Y != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));

///////////////////////

if (X != 0)
{
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
}
else
{
if (Y != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
}

 

[Mattias Sjögren]

Andrew,

if (X != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
else

Your indentation is misleading, the else pairs with the second if
statement.

if (X != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
else


Mattias

 

[Andrew Bullock]

Andrew,


Your indentation is misleading, the else pairs with the second if
statement.

if (X != 0)
if ((float)(nud.Value) > 0.0)
coords.Add(new Coord(X, Y, (float)(nud.Value)));
else


Mattias

Oh of course!

Idiot!!

Can you tell I've been working all day?



Thanks
Andrew

 

[Nick Hounsome]

This is precisely why every coding standard ever written mandates the use of
braces.

C# is unnecessarily picky in all sorts of areas (e.g. forbidding the use of
redundant access qualifiers) so it is slightly odd that MS allow both braced
and braceless constructs.

 

[Jon Skeet [C# MVP]]

This is precisely why every coding standard ever written mandates the use of
braces.

C# is unnecessarily picky in all sorts of areas (e.g. forbidding the use of
redundant access qualifiers) so it is slightly odd that MS allow both braced
and braceless constructs.

Indeed. It's particularly unfortunate that the part of the ECMA
language specification which smugly (and accurately) claims the
benefits of having a "bool" type uses the following code:

int i = ...;
F(i);
if (i = 0) // Bug: the test should be (i == 0)
G();

It demonstrates the superiority of C# in one respect, which
unfortunately showing that another problem of C *hasn't* been fixed

Jon

 

[Nick Hounsome]

Indeed. It's particularly unfortunate that the part of the ECMA
language specification which smugly (and accurately) claims the
benefits of having a "bool" type uses the following code:

int i = ...;
F(i);
if (i = 0) // Bug: the test should be (i == 0)
G();

It demonstrates the superiority of C# in one respect, which
unfortunately showing that another problem of C *hasn't* been fixed

In this day and age I would be "dissapointed" in any C/C++ compiler that
didn't flag it as a warning.

[It is totally trivial to implement because you just need to look for an
assignment at the root of the condition parse tree]

 

[Mike]

IMHO the right way to fix this is to just make indentation significant a la
Python, and loose the braces (except for obfuscated or auto-generated code)
all-together. With anonymous delegates, some type inference and tuple-syntax
coming, C# would be the best of most worlds if it looked as nice as
Python...

m

 

[Jon Skeet [C# MVP]]

IMHO the right way to fix this is to just make indentation significant a la
Python, and loose the braces (except for obfuscated or auto-generated code)
all-together. With anonymous delegates, some type inference and tuple-syntax
coming, C# would be the best of most worlds if it looked as nice as
Python...

I'm very nervous of white-space being significant. It makes cut and
paste a much riskier business, for starters. Then again, I haven't used
Python significantly - maybe one gets used to being careful.

Personally I'd be happy with the braces being compulsary.

 

[Nick Hounsome]

I'm very nervous of white-space being significant. It makes cut and
paste a much riskier business, for starters. Then again, I haven't used
Python significantly - maybe one gets used to being careful.

No - You just need an intelligent IDE.

[it's only a problem if you use tabs and they are not expanded - the IDE has
to ssume either 8 or whatever you have set (which could be a proble,) - it's
certainly not a problem between bits of your own code]

Personally I'd be happy with the braces being compulsary.

I suppose that you can just use FxCop or something similar to enforce it(?)

 

[Mike]

No - You just need an intelligent IDE.

Yes, the editors seem to be good at doing the right thing. (I think the lack
of braces is actually less error-prone, not more.)
Also, Python functions, because the "noise"/code ratio is smaller, tend to
be much smaller than c# functions, so there isn't much chance of messing
things up too bad with repsect to indentation. (Hopefully closures and type
inference will help c# as well.) C#'s Odes map to a bunch of smaller Python
Haikus. (Of course Python has it's own set of issues...)

[it's only a problem if you use tabs and they are not expanded - the IDE
has to ssume either 8 or whatever you have set (which could be a
proble,) - it's certainly not a problem between bits of your own code]

Personally I'd be happy with the braces being compulsary.

To me something being compulsary syntactically is a prime pointer to its
lack of necessity - if it *has* to be there, the compiler should figure it
out. (I will conveniently omit all cases to the contrary...)

m

 

[Jon Skeet [C# MVP]]

To me something being compulsary syntactically is a prime pointer to its
lack of necessity - if it *has* to be there, the compiler should figure it
out. (I will conveniently omit all cases to the contrary...)

That would be fine if the only thing which read code was the compiler.
However, it's not - there's the reader, too.

There's no *need* for the colon between the name of a class and the
interfaces it implements or its base classes, nor the commas between
those. For instance, you could have:

public class Foo BaseClass ISomeInterface

Similarly there's no need for commas between parameters:

public void Foo (int i long j string x)

I'm jolly glad both of those exist though - the above are both
nightmares to read.

For me, braces add to readability - they mean that things *can't* get
screwed up just because of indentation, and I can use indentation to
make things more readable, breaking up lines and lining things up in
places which look better to *me* rather than to the compiler.

The braces thing is a personal issue, but I hope you see my point about
the counter-examples to your general suggestion

 

[Mike]

That would be fine if the only thing which read code was the compiler.
However, it's not - there's the reader, too.

There's no *need* for the colon between the name of a class and the
interfaces it implements or its base classes, nor the commas between
those. For instance, you could have:

public class Foo BaseClass ISomeInterface

Similarly there's no need for commas between parameters:

public void Foo (int i long j string x)

I'm jolly glad both of those exist though - the above are both
nightmares to read.

For me, braces add to readability - they mean that things *can't* get
screwed up just because of indentation, and I can use indentation to
make things more readable, breaking up lines and lining things up in
places which look better to *me* rather than to the compiler.

Yes, but you can always indent such that the indentaion does not match the
true nesting. (Although that's harder to do these days.)

The braces thing is a personal issue, but I hope you see my point about
the counter-examples to your general suggestion

Sure I do - hence my comment:

I will conveniently omit all cases to the contrary...

I'm not sure about your slippery-slope argument about the colon and commas
above -- I certainly agree that these items shoud be there for readability.
That fact that I use mainly C# and not Python for most of my projects shows
I'm not religious about this issue, but in this case I think Python has the
edge on readability.

Consider:

if ( minute >= 0 && minute < 60 && second >=0 && second < 60)
{
foo(1);
for each ( int e in coll)
{
bar(e);
}
}

vs.

if 0 <= minute < 60 and 0 <= second < 60:
foo(1)
for e in coll:
bar(e)

Python, by not needing braces and statement seperators, not strickly
requiring outer parens, and handling the inequality nicely seems really easy
to read to me (in addition to taking up less room), and there's really no
mistaking what's going on with the indentation.
On the other hand, there's not quite enough sugar around its
object-orientated features, IMHO.

But luckily, the smart editor's have really rendered most of this moot...

m

 

[Jon Skeet [C# MVP]]

Yes, but you can always indent such that the indentaion does not match the
true nesting. (Although that's harder to do these days.)

So in a situation where the compiler was highly sensitive to
whitespace, what would it do?

I'd like to call "make" to the witness stand to give evidence of how
harmful whitespace can be to getting things right, by the way.

Sure I do - hence my comment:

I thought I'd point out just how far it went anyway...

I'm not sure about your slippery-slope argument about the colon and commas
above -- I certainly agree that these items shoud be there for readability.
That fact that I use mainly C# and not Python for most of my projects shows
I'm not religious about this issue, but in this case I think Python has the
edge on readability.

Python, by not needing braces and statement seperators, not strickly
requiring outer parens, and handling the inequality nicely seems really easy
to read to me (in addition to taking up less room), and there's really no
mistaking what's going on with the indentation.

Actually, I think that taking away the parentheses decreases the
readability. The braces? I could see it either way. The good thing
(IMO) is that it makes everything absolutely explicit when braces are
everywhere.

On the other hand, there's not quite enough sugar around its
object-orientated features, IMHO.

But luckily, the smart editor's have really rendered most of this
moot...

We don't have smart editors in newsgroup posts, though - or in web
pages, emails etc. I see plenty of code in many places where the
indentation isn't as it was intended to be. When whitespace is
unimportant, that's okay - the editor can reformat the code
appropriately when you paste it back, because it still has the
information.

Whitespace is so easy to get wrong - why make the meaning of a language
absolutely depend on getting it right?

 

[Mike]

So in a situation where the compiler was highly sensitive to
whitespace, what would it do?

I'd like to call "make" to the witness stand to give evidence of how
harmful whitespace can be to getting things right, by the way.


I thought I'd point out just how far it went anyway...




Actually, I think that taking away the parentheses decreases the
readability. The braces? I could see it either way. The good thing
(IMO) is that it makes everything absolutely explicit when braces are
everywhere.


We don't have smart editors in newsgroup posts, though - or in web
pages, emails etc. I see plenty of code in many places where the
indentation isn't as it was intended to be.
...

Yes, this argument is valid and I beleive well-discussed by Pythonistas.

Whitespace is so easy to get wrong - why make the meaning of a language
absolutely depend on getting it right?

I don't think that this should be the case - it should always be possible to
be explicit, by allowing braces if you feel it is necessary. (I think
there's been talk in a PEP about this, if I recall.)

We're only talking about whitespace being significant in one place: before
anything else starts on a line, for the purpose of control structure
nesting - I agree that having "inner" whitespace or any other whitespace
significant would be a nightmare. (At least we're not talking fortran -
'DOI,J
Artificial languages are explicit by nature, I agree - but you brought up
"readability", which is really treading into natural language processing
territory, at least with respect to getting a "gestalt" feel for what code
is doing by glancing at it, and in this case I personally find that Python
has a slight win in the case of indentation == actual structure. (At lease
most of the time -- an escape is fine.)

Anyway, I feel I'm being called to devil's advocate for a position I said I
wasn't religious about, so I stop here...

m

 

[Jon Skeet [C# MVP]]

Yes, this argument is valid and I beleive well-discussed by Pythonistas.


I don't think that this should be the case - it should always be possible to
be explicit, by allowing braces if you feel it is necessary. (I think
there's been talk in a PEP about this, if I recall.)

Ah, now that's a different matter. (I haven't actually done enough
Python to even know whether they're currently available in the first
place.)

We're only talking about whitespace being significant in one place: before
anything else starts on a line, for the purpose of control structure
nesting - I agree that having "inner" whitespace or any other whitespace
significant would be a nightmare. (At least we're not talking fortran -
'DOI,J

Yes - but often whitespace *is* at the start of a line for the sake of
making things readable, whether it's a control structure introduction
or not. Is it only significant on certain lines in Python?

Artificial languages are explicit by nature, I agree - but you brought up
"readability", which is really treading into natural language processing
territory, at least with respect to getting a "gestalt" feel for what code
is doing by glancing at it, and in this case I personally find that Python
has a slight win in the case of indentation == actual structure. (At lease
most of the time -- an escape is fine.)

Anyway, I feel I'm being called to devil's advocate for a position I said I
wasn't religious about, so I stop here...

I definitely need to actually *do* significant amounts of Python before
I can really judge in an informed way - but it *feels* like a dangerous
thing to do, to me. No doubt I'll change my mind, possibly several
times, in the next few years...