More than a style issue?

[GlennDoten]

On Aug 12 at 4:31 in the thread titled

"What's 'best practice'--instantiate in the constructor or outside it
for collection class?"

http://www.bartdesmet.net/images/CQuizFieldinitializationcontd_B5D2/image0_thumb4.png

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

A random early Sunday morning question. I suppose it is simply a matter
of style. Any deeper reasons than that?

 

[Nicholas Paldino [.NET/C# MVP]]

I think that some people prefer clairity. Maybe some are paranoid and
think the defaults will change (I don't, that would be wholly unreasonable).
More often than not, I think it is the former, people just prefer the
clarity.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

On Aug 12 at 4:31 in the thread titled

"What's 'best practice'--instantiate in the constructor or outside it for
collection class?"

http://www.bartdesmet.net/images/CQuizFieldinitializationcontd_B5D2/image0_thumb4.png

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

A random early Sunday morning question. I suppose it is simply a matter of
style. Any deeper reasons than that?

 

[Guest]

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

You should always explicit specify access modifier.

Arne

 

[GlennDoten]

You should always explicit specify access modifier.

So they why do you think the language makes it optional?

 

[Anthony Jones]

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

You should always explicit specify access modifier.

Why?

 

[Guest]

So they why do you think the language makes it optional?

There is a big difference between required by the language
and what is good style in many other areas.

Languages like C++ and Java also has default access modifiers.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

You should always explicit specify access modifier.

Why?

To make the code more readable.

You may remember what the default is, but not everybody does.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

GlennDoten wrote:
Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't
mean to
pick on your code; it just made me think to ask the following
question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?
You should always explicit specify access modifier.

Why?

To make the code more readable.

You may remember what the default is, but not everybody does.

It is like putting plenty of () in expressions.

You may have memorized the operator precedence table, but
do not assume that the maintenance programmer taking over your
code also has.

Arne

 

[Jon Skeet [C# MVP]]

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

A random early Sunday morning question. I suppose it is simply a matter
of style. Any deeper reasons than that?

I miss them out when they're optional, for the sake of clarity. It
doesn't make *those* declarations clearer, but it makes *others*
clearer. The defaults in C# always go for the most private possible
option (with one exception when you are making one part of a property
more private than the property itself). Now, if I've got code like
this:

int Method1() {...}

int Method2() {...}

int Method3() {...}

public int Method4() {...}

then it calls attention to the "public" - it makes me think, "Did I
really want to make this public?"

That's my reasoning.

 

[Jon Skeet [C# MVP]]

You should always explicit specify access modifier.

Why? I've given my reasons in another post - by leaving out the
optional ones, it draws attention to where I'm doing anything *other*
than the default.

 

[Jon Skeet [C# MVP]]

To make the code more readable.

On that we differ, for reasons stated elsewhere.

You may remember what the default is, but not everybody does.

True - but that then depends on who you're writing for. If you're
talking about professional code and you deem all your colleagues to be
competent (as I do) then it's not a problem. I expect my colleagues to
either know the defaults or be smart enough to ask or look them up when
it matters.

Note that the defaults in C# being what they are, it's almost never a
mistake to leave off the explicit modifier - if something is more
*private* than it should be, you'll almost always get a compilation
error.

 

[GlennDoten]

There is a big difference between required by the language
and what is good style in many other areas.

Right, I've already said it is a style issue. I'm just wondering if
people might have a "deeper" reason for doing it other than stylistic
concerns.

I guess I can't help asking why the language has made some of these
issues optional? Anything deeper than "because they can be?"

 

[GlennDoten]

Looking at this posted code made me think of the issue of optional
keywords and their usage (or lake of usage). [UL-Tomten, I don't mean to
pick on your code; it just made me think to ask the following question.]

I always wondered why people write

class Foo

yet write

private int i;

instead of

int i;

Or, more generally, why use (or not use) optional keywords at all?

A random early Sunday morning question. I suppose it is simply a matter
of style. Any deeper reasons than that?

I miss them out when they're optional, for the sake of clarity. It
doesn't make *those* declarations clearer, but it makes *others*
clearer. The defaults in C# always go for the most private possible
option (with one exception when you are making one part of a property
more private than the property itself). Now, if I've got code like
this:

int Method1() {...}

int Method2() {...}

int Method3() {...}

public int Method4() {...}

then it calls attention to the "public" - it makes me think, "Did I
really want to make this public?"

That's my reasoning.

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

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

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 know that coding standards meetings would go a lot smoother if the
language did not allow multiple ways to express these things. (But then
the meetings would be a lot more boring too!)

 

[Jon Skeet [C# MVP]]

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.

 

[GlennDoten]

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)
{
....
}

Interesting, I thought that would give a compiler error, but it is just
a warning. What the compiler warning is saying that you are effectively
doing this:

if (true)
{
...
}

(Although you deserve what you get if you are doing things like
"x==true" in a conditional anyhow!)

I guess I've only mis-coded these:

int x;
if (x=13)
{
...
}

which does give a compiler error.

I've always known about this idiom:

StreamReader sr = File.OpenText("a.b");
string line;
while ((line = sr.ReadLine()) != null)
{
// process the line
}

although I hardly use that, favoring something like this:

string line = sr.ReadLine();
while (line != null)
{
// process the line
line = sr.ReadLine();
}

because I think this is clearer and hence easier to maintain.

FWIW.

 

[Jon Skeet [C# MVP]]

I've always known about this idiom:

StreamReader sr = File.OpenText("a.b");
string line;
while ((line = sr.ReadLine()) != null)
{
// process the line
}

although I hardly use that, favoring something like this:

string line = sr.ReadLine();
while (line != null)
{
// process the line
line = sr.ReadLine();
}

because I think this is clearer and hence easier to maintain.

I prefer the first one. It's a sufficiently well-known idiom that I'd
expect colleagues to be familiar with it, and it avoids repetition. If
ever you wanted something different instead of ReadLine, you'd need to
remember to change the "reading" code in two places. I *think* I have
vague memories of seeing a bug caused by someone making exactly this
mistake, but I could certainly be wrong.

As they say: de gustibus non est disputandum.

 

[GlennDoten]

I prefer the first one. It's a sufficiently well-known idiom that I'd
expect colleagues to be familiar with it, and it avoids repetition. If
ever you wanted something different instead of ReadLine, you'd need to
remember to change the "reading" code in two places. I *think* I have
vague memories of seeing a bug caused by someone making exactly this
mistake, but I could certainly be wrong.

I almost added that I don't mind the second idiom because I pretty much
would never do a "straight" sr.ReadLine call but would wrap that in a
method which would do line counting, skipping blank lines, and that sort
of thing. But point taken.

The thing I don't like, in terms of clarity, with the first idiom is
that it leads to much more complex variations on that theme. (Start with
the weed and next week your on the heroin...)

 

[Guest]

Right, I've already said it is a style issue. I'm just wondering if
people might have a "deeper" reason for doing it other than stylistic
concerns.

Good style is not for stylistic concerns but for readability.

I guess I can't help asking why the language has made some of these
issues optional? Anything deeper than "because they can be?"

As I wrote C++ and Java has it too, so it can be leftover
baggage.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

True - but that then depends on who you're writing for. If you're
talking about professional code and you deem all your colleagues to be
competent (as I do) then it's not a problem.

Congratulation with knowing that it will be first class programmers
maintaining your code the next 10-20 years.

But that is not the general case.

Which is why it is good practice to write code that even the
below average programmer can maintain.

I expect my colleagues to
either know the defaults or be smart enough to ask or look them up when
it matters.

But they are paid to lookup things to understand your code. You are
paid to produce code that they can understand without looking anything
up.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

But they are paid to ...

But they are not paid to ...

Arne