I suppose the onus of creating "readable" code always falls to the
individual developer.
Agreed.
I just wonder to what extent some language features
invite or encourage "lazy" coding.
Some do - but some have the opposite effect. Consider automatically
implemented properties. A lazy programmer might normally decide to
expose a public field:
public class Person
{
public string Name;
}
They might think, "I know it *should* be a property, but it doesn't
hurt to be a field and the property would just be boilerplate code
anyway, adding to code bloat without doing anything."
With C# 3 they can write:
public class Person
{
public string Name { get; set; }
}
It's really, really easy to turn it into a property, which gives you
the correct encapsulation from the start, and extra code can be added
(e.g. for validation) without changing the actual API.
I'm not an early adopter of new language
features, but I don't think I'm afraid of them either. I am, however, a
little scared when they come with names like "partial methods" (where is the
rest of it?)
Partial methods are to do with partial types - hard to explain very
briefly, I'm afraid.
"Implicitly typed variables" (what's wrong with explicit
types?)
Well:
Dictionary<string,IList<string>> phoneNumberMap =
new Dictionary<string,IList<string>>();
isn't as nice in my view as:
var phoneNumberMap = new Dictionary<string,IList<string>>();
The latter has less redundancy.
It's also necessary for anonymous typing...
and "anonymous types" (you don't want me to know what type it is?).
Often in LINQ, you end up wanting to encapsulate things just for the
purposes of one method. The compiler can build a type for you in order
to do that simply, and you can always change it into a "real" type
later if you really want.
To be honest, I'm unlikely to convince you in the time I've got for
this post - it's worth seeing genuine code to understand the benefits.
I'm sure that there is a time and a place for these features, just like
there is probably a time and a place for overloading the "+" operator to
actually perform subtraction in C++. But is it worth it? I suppose that's
not only a subjective and rhetorical question, but one's answer probably
changes over time.
The interesting thing to me is that C# 3 encourages a whole shift of
mindset, to a more functional viewpoint - where it's useful, of course.
I think it will be a while before most developers (myself included) get
the most out of the new features. It can be really lovely though.
I read some C# code today where all of the local
variables were declared (but not initialized) at the top of the routine. I
chuckled, because I used to do that.
Yes, it's kinda sad how easy it is to move idioms over from one
language to another for no reason. Likewise I sometimes see C# code
such as:
if (5==i)
or
if (null==foo)
I know why people do that in C++, but the reason is gone for almost
every situation in C#. It's less readable than putting the constant
second, so why propagate the habit?
