471,348 Members | 1,186 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,348 software developers and data experts.

missing out braces

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)));
}
Feb 18 '06 #1
14 1501
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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Feb 18 '06 #2
Mattias Sjögren wrote:
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


Oh of course!

Idiot!!

Can you tell I've been working all day?

:(

Thanks :)
Andrew
Feb 18 '06 #3
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.
Feb 20 '06 #4
Nick Hounsome wrote:
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

Feb 20 '06 #5

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Nick Hounsome wrote:
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 :(


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]
Feb 20 '06 #6

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Nick Hounsome wrote:
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.

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

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

Feb 20 '06 #7
Mike <vi********@yahoo.com> wrote:
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.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 20 '06 #8

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:
>> 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.
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.


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(?)
Feb 21 '06 #9

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:8Q******************@fe3.news.blueyonder.co.u k...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:
>> 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.

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.


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

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

Feb 21 '06 #10
Mike <vi********@yahoo.com> wrote:

<snip>
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...)


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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 21 '06 #11

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:

<snip>
>> 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...)


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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Feb 21 '06 #12
Mike <vi********@yahoo.com> wrote:
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.)


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.
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 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.
<snip>
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 21 '06 #13

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:
> 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.)


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.
> 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 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.


<snip>
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.
...


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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Feb 21 '06 #14
Mike <vi********@yahoo.com> wrote:
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.)


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...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 21 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

97 posts views Thread by Kjetil Torgrim Homme | last post: by
16 posts views Thread by Jason | last post: by
3 posts views Thread by Old Wolf | last post: by
12 posts views Thread by Pawel | last post: by
2 posts views Thread by mauricioarango | last post: by
cat
22 posts views Thread by Jag | last post: by
4 posts views Thread by =?Utf-8?B?VG9yZW4gVmFsb25l?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.