More than a style issue?

[Jon Skeet [C# MVP]]

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

That's certainly a valid concern, but for some reason I don't see it as
a problem in real life - I can't remember any bad code I've seen which
looks like it has its stem in this idiom.

 

[Jon Skeet [C# MVP]]

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.

Does that mean you'll never use any captured variables, lambda
expressions etc? What about generics? They're pretty tricky in places.

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.

You only need to look it up once - it's an incredibly easy rule to
remember.

 

[GlennDoten]

Good style is not for stylistic concerns but for readability.

Right. In the context of this thread: style = clarity = readability. I
think what I'm saying then is that if it's good style then why doesn't
the language require it? Perhaps the language designers couldn't agree
on what the best style is?

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

I would be extremely surprised if that were the reason. It sure seems to
me that the language designs thought long and hard on C# and wouldn't
allow baggage for that sake. But then who knows?

 

[Jon Skeet [C# MVP]]

Right. In the context of this thread: style = clarity = readability. I
think what I'm saying then is that if it's good style then why doesn't
the language require it? Perhaps the language designers couldn't agree
on what the best style is?

I think you need a wider context than style=clarity=readability.

My preferred style doesn't make any one declaration more readable -
indeed it slightly *decreases* the readability of private
declarations. I take that hit because I believe it *increases* the
clarity of the code as a whole, by drawing attention to non-private
declarations.

Jon

 

[Guest]

Right. In the context of this thread: style = clarity = readability. I
think what I'm saying then is that if it's good style then why doesn't
the language require it?

That is usually not considered within the scope of the language itself.
I am not aware of any language that enforces good style and conventions.

It is left to external tools (FxCop is an example of such for .NET).

Can you imagine the compiler give errors on wrong naming convention, bad
indentation, too long methods, missing comments etc. ?

Perhaps the language designers couldn't agree
on what the best style is?

MS has published recommendations on somethings that goes beyond language
definition.

I would be extremely surprised if that were the reason. It sure seems to
me that the language designs thought long and hard on C# and wouldn't
allow baggage for that sake. But then who knows?

I think it is obvious from the result that "look and feel compatibility"
with C++ and Java has been a major design goal for C#.

Arne

 

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

Does that mean you'll never use any captured variables, lambda
expressions etc? What about generics? They're pretty tricky in places.

Most features can be used to both write more readable code and
to write very obfuscated code.

Generics/templates can be used to write very nice code. But they
can definitely also be misused to write unmaintainable code
(for the average maintenance programmer). The C# way of generics
is not the worst in that regard though.

Arne

 

[Jon Skeet [C# MVP]]

Most features can be used to both write more readable code and
to write very obfuscated code.

Generics/templates can be used to write very nice code. But they
can definitely also be misused to write unmaintainable code
(for the average maintenance programmer). The C# way of generics
is not the worst in that regard though.

Sure - but my point is that if you're targetting the real lowest common
denominator, you shouldn't use generics at all - below average
programmers are unlikely to have a decent grip on the concepts
involved.

I'd argue that using generics (nicely - I'm not talking about going
over the top here) will confuse a poor programmer far more than using
the default access level.

 

[Steven Nagy]

Sure - but my point is that if you're targetting the real lowest common
denominator, you shouldn't use generics at all - below average
programmers are unlikely to have a decent grip on the concepts
involved.

I'd argue that using generics (nicely - I'm not talking about going
over the top here) will confuse a poor programmer far more than using
the default access level.

I can understand the point you are trying to make Jon.
I just changed jobs. At my last location I was discouraged from using
"Abstract Classes" and "Interfaces" and "Design Patterns" simply
because the lowest common denominator wouldn't understand those
principles. Theoretically the LCD would be someone who knows the
basics of selection, iteration, and variables. But as OO programmers
we can't maintain that standard of code (which is why I left the
company).

The worst of it is that there are guys at that company who will think
that there's no point learning those things for those very reasons. By
putting more advanced coding concepts (implemented correctly) into our
applications, we raise the standard of our developers.

You get better at playing chess if you play against Kasparov rather
than my Dachshund.

 

[GlennDoten]

That is usually not considered within the scope of the language itself.
I am not aware of any language that enforces good style and conventions.

It is left to external tools (FxCop is an example of such for .NET).

Can you imagine the compiler give errors on wrong naming convention, bad
indentation, too long methods, missing comments etc. ?

Good point. And no I couldn't imagine that! But I'm thinking more about
syntactical elements of the language that seem to be a coin toss.
Clearly, curly braces aren't required around a one statement part of an
if statement in order for the compiler to do it's syntax analysis. It's
also not required--for syntax analysis purposes--that the language
require a case statement be terminated and not fall through to the next.
Yet the language designers, for the sake of clarity, made the latter a
requirement but not the former.

MS has published recommendations on somethings that goes beyond language
definition.

Yes, but no one follows them completely, including MS. "The great thing
about standards is that there are so many to choose from."

I think it is obvious from the result that "look and feel compatibility"
with C++ and Java has been a major design goal for C#.

I suppose that makes sense, except in the cases where they quite
deliberately took away that look-and-feel compatibility for the sake of
clarity.

 

[Guest]

Good point. And no I couldn't imagine that! But I'm thinking more about
syntactical elements of the language that seem to be a coin toss.
Clearly, curly braces aren't required around a one statement part of an
if statement in order for the compiler to do it's syntax analysis. It's
also not required--for syntax analysis purposes--that the language
require a case statement be terminated and not fall through to the next.
Yet the language designers, for the sake of clarity, made the latter a
requirement but not the former.

I think that one is also to some extent historical determined.

There are a long tradition in lots of languages to allow single
statements in places of blocks.

Fall through cases is not nearly as widely used.

Another language that allows the first but not the second
is Pascal.

Maybe Anders Hejlsberg had something to say.

Yes, but no one follows them completely, including MS. "The great thing
about standards is that there are so many to choose from."

The only way to ensure that they coding conventions are followed are
to run a checking tool and have developers "fix" non conformant code.

Arne

 

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

Sure - but my point is that if you're targetting the real lowest common
denominator, you shouldn't use generics at all - below average
programmers are unlikely to have a decent grip on the concepts
involved.

I disagree.

In many cases generics make the code more easy to read and
understand.

I'd argue that using generics (nicely - I'm not talking about going
over the top here) will confuse a poor programmer far more than using
the default access level.

I disagree.

void Foobar()

public void Foobar()

In the last one Joe not so smart can see accessvility without
having to check the C# manual.

public void Foobar(ArrayList lst)

public void Foobar(List<String> lst)

In the last one Joe not so smart can see more about what that
list actually contains without checking docs or other code.

It is all about readability.

Arne

PS: And my apologies to all the Joe's ....

 

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

I can understand the point you are trying to make Jon.
I just changed jobs. At my last location I was discouraged from using
"Abstract Classes" and "Interfaces" and "Design Patterns" simply
because the lowest common denominator wouldn't understand those
principles. Theoretically the LCD would be someone who knows the
basics of selection, iteration, and variables. But as OO programmers
we can't maintain that standard of code (which is why I left the
company).

The worst of it is that there are guys at that company who will think
that there's no point learning those things for those very reasons. By
putting more advanced coding concepts (implemented correctly) into our
applications, we raise the standard of our developers.

Abstract classes and interfaces adds functionality to the coding
that has other benefits.

That is somewhat different from the topic of using defaults instead
of explicit.

You get better at playing chess if you play against Kasparov rather
than my Dachshund.

Arne

 

[Jon Skeet [C# MVP]]

I disagree.

In many cases generics make the code more easy to read and
understand.

So long as you understand them, yes... but if you have to *change* the
code, you really do need to know what's going on.

I disagree.

void Foobar()

public void Foobar()

In the last one Joe not so smart can see accessvility without
having to check the C# manual.

True - I've never disputed that being explicit makes an *individual*
line of code clearer. I believe, however, that using the defaults makes
the code *as a whole* clearer.

public void Foobar(ArrayList lst)

public void Foobar(List<String> lst)

In the last one Joe not so smart can see more about what that
list actually contains without checking docs or other code.

Try this one then:

public void Foobar(List<Object> lst)


Now code of:
List<String> strings = new List<string>();
Foobar(strings);

Poor Joe now gets very confused... how often do we see questions about
covariance and contravariance on this group? What about constraints,
type inference, overloading choices etc? Generics is a *huge* topic
with lots of gotchas that are very easy to run into.

It is all about readability.

I think we all agreed that a long time ago - at least if you include
"clarity" as part of readability.

 

[GlennDoten]

void Foobar()

public void Foobar()

In the last one Joe not so smart can see accessvility without
having to check the C# manual.

I think you've summed up my whole point right there. If the language did
not allow the accessibility specifier to be optional, then Joe
not-so-smart would have no option but to learn the syntax of the
language. For newbies, or the not-so-smart, or just those with a bad
memory, they are forced to go to the docs when uncertain about an
optional element.

I think the compiler issuing an error message "'public' in this context
is not necessary and therefore must be removed" in the second example
would be a Good Thing. (It's the opposite of the existing error message
"<token> expected".) Or if the language didn't allow them to be optional
then: "accessibility specifier is missing" for the first example.