Jon said:
So use VB.NET instead - there's very little not to, if you don't like C
style syntax.
Well, that thought did pass through my mind; but then, it's too VB-ish
for my liking.
I /do/ understand that VB.NET is just an interface to MSIL, as is C#,
but I s'pose I'm prejudiced when it comes to anything VB or VB-like
There are more important reasons, though, that I mention in a moment.
Why get annoyed by a language (and moan in an unconstructive way to
those who *do* like it)
I s'pose I'm just interested in people's views on this.
when there's a perfectly viable alternative?
The thing with C# is that it's *the* programming language for .NET (or,
at least, I think so). I think that whenever a new feature is added to
the framework, C# will be the first to get it. C# will be the one that
sticks around longer. C# is the one that has more use in the industry,
and is more widely-used in general. etc.
Personally I'm very happy that C# is just the way it is, and wouldn't
like it to be any more like VB.NET (aside from having named indexers).
There are parts of C# that I like, but some parts are so annoying. The
most annoying and anti-readability element of any C-like language, in my
opinion, is the 'return' construct.
Here's an example of some code that demonstrates my point:
FontTagElement GetFontTagElement()
{
//...
if (length == SingleElementPartCount) {
if (arr[FirstIndex] == FontNameSpecifier) {
string name = arr[FirstIndex];
return new FontTagElement(name);
} else {
int size = TryStringToInt(arr[FirstIndex]);
return new FontTagElement(size);
}
} else if (length == DualElementPartCount) {
string name = arr[FirstIndex];
int size = TryStringToInt(arr[SecondIndex]);
return new FontTagElement(name, size);
} else {
return null;
}
}
To be consistent with simpler uses of 'return', the above code should be
re-written as:
FontTagElement GetFontTagElement()
{
//...
if (length == SingleElementPartCount) {
if (arr[FirstIndex] == FontNameSpecifier) {
string name = arr[FirstIndex];
return new FontTagElement(name);
}
int size = TryStringToInt(arr[FirstIndex]);
return new FontTagElement(size);
}
if (length == DualElementPartCount) {
string name = arr[FirstIndex];
int size = TryStringToInt(arr[SecondIndex]);
return new FontTagElement(name, size);
}
return null;
}
So one can choose either readability or consistency, but not both.
Here's the above slightly changed to show a more Delphi-like returning
construct:
FontTagElement GetFontTagElement()
{
//...
if (length == SingleElementPartCount) {
if (arr[FirstIndex] == FontNameSpecifier) {
string name = arr[FirstIndex];
result = new FontTagElement(name);
} else {
int size = TryStringToInt(arr[FirstIndex]);
result = new FontTagElement(size);
}
} else if (length == DualElementPartCount) {
string name = arr[FirstIndex];
int size = TryStringToInt(arr[SecondIndex]);
result = new FontTagElement(name, size);
} else {
result = null;
}
}
Voilà -- no loss of readability and no inconsistency!
Isn't it a good thing that each of us can have a language which works
the way we want?
That sounds great. If I ever believe to have found such a language,
I'll be sure to let the group know
