Re: More than a style issue?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

GlennDoten <gdoten@xxxxxxxxx> wrote:

<snip>

Personally, I agree with what you've said, and that's how I happen to
write my code too.

I guess what I'm wondering is why does the language allow defaults like
this? If it didn't, it seems to me that the code would be crystal clear
in all instances.

It would be clear for each individual declaration, but it wouldn't draw
attention to the non-private declarations.

Perhaps it is just this sense of "completeness" a lot
of us have: "well, this field can be internal, protected, public,
internal protected, or private; we better have keyword(s) for each of
those 'just for completeness'."

Possibly. I couldn't say for sure, to be honest.

It's like with curly braces:

if (foo) doSomething();

is the same as:

if (foo) { doSomething(); }

Since a lot of people seem to think that the curly braces should always
be there, for stylistic (i.e., clarity) reasons, then why make them
optional?

I'm with you on that one. The funny thing is that the ECMA spec
contains this (section 8.2.1):

<quote>
The bool type is used to represent Boolean values: values that are
either true or false. The inclusion of bool
makes it easier to write self-documenting code; it also helps eliminate
the all-too-common C++ coding error
in which a developer mistakenly uses =3F==3F when =3F===3F should have been
used. In C#, the example
int i = =3F;
F(i);
if (i = 0) // Bug: the test should be (i == 0)
G();
</quote>

In other words, when highlighting a deficiency in C++ the example given
is just *waiting* for a different kind of bug to be introduced.

I mean, the language requires a break (or some other "exit")
from each and every case in a switch statement because this is much
clearer than what, say, C allows in this regard. And it doesn't allow =
in an if statement the way C does (another good decision, but, again,
some would consider a missing feature). And there's probably other examples.

It *does* allow assignment in "if" statements - the difference is that
it doesn't have an implicit conversion from arbitrary values to a
boolean, and an "if" only accepts a boolean expression. You can still
accidentally do:

bool x = false;
if (x=true)
{
....
}

Maybe the question I'm trying to get to is why did the language
designers take out what some would consider features (case statements
falling through to the next) for nothing more than the sake of clarity
(and I do like this far better than what C allows), yet allow some
optional keywords and optional braces cloud things back up?

I've never seen any justification for this decision. However, at least
the default is a good one - the Java one is awful, for instance.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • [PATCH] drivers/block/DAC960: Converted boolean to bool
    ... Converts 'boolean' to 'bool' and removes the 'boolean' typedef. ... unsigned char CommandOpcode2, ... typedef struct DAC960_SCSI_RequestSense ...
    (Linux-Kernel)
  • [PATCH] drivers/video/sis: Convert to generic boolean
    ... BOOLEAN -> bool ... Have followed all function/variable paths who been converted to 'bool' ... SiS_GetModeID(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDisplay, ...
    (Linux-Kernel)
  • Re: Weird problem calling DLL
    ... afaik a Delphi boolean is not ... always equal to a bool also. ... *neither* language defines the binary representation of the types. ...
    (comp.lang.pascal.delphi.misc)
  • Re: missing xor Boolean operator
    ... When I was talking about such error prone form of boolean operations, ... is nothing in python that forces you to be "false" if you are empty, ... one should care more about how an object /behaves/ than ... you shouldn't care if you have a bool instance - it should ...
    (comp.lang.python)