I've Had Enough

[C# Learner]

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

[C# Learner]

Julie wrote:

I'll take the language any day. It is their sucky, buggy, deficient IDE that
gets my goat, day after day.

So far, their IDE can handle "hello world" class projects, but not much more...

The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

[C# Learner]

Reginald Blue wrote:

[...]
Just promise us that you won't start coding in Cobol.NET.

Well, I've never touched Cobol, so I can't appreciate how horrible it
might be, but I can tell you for certain that I'd never remotely
consider using Fortran! :-)

[Julie]

C# Learner wrote:

Julie wrote:

I'll take the language any day. It is their sucky, buggy, deficient IDE that
gets my goat, day after day.

So far, their IDE can handle "hello world" class projects, but not much more...

The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.

I'm currently working on one solution composed of maybe 30-40 projects of C#,
managed C++, and native C++, with multiple forms, controls, etc.

It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a project
because somewhere else the IDE has a file open (in this case, a debugging pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.

A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.

[Daniel Pratt]

Hi C# Learner,

"C# Learner" <cs****@learner.here> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

No language that I've encountered would I consider perfect. Not even
close. Any language that I've seen is either filled with compromises or is
practically useless (or both). Have you found a language you like better, or
are you considering another vocation?

Regards,
Daniel

[C# Learner]

Daniel Pratt wrote:

Hi C# Learner,

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
No language that I've encountered would I consider perfect.

I feel the same :-)
Not even
close. Any language that I've seen is either filled with compromises or is
practically useless (or both). Have you found a language you like better, or
are you considering another vocation?

I've been a Delphi person for some years. Delphi's a language that, I
feel, makes writing clear code easy, and writing hard-to-read code
difficult. With that said, I don't feel Delphi is perfect.

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(

C# is a nice language in some ways, but it's too inhibited by
C/C++/Java, IMO.

I think that the ideal language would combine the best parts of C# and
Delphi.

I may, at some point in the future, design such a language mainly for
fun, and perhaps even make an MSIL compiler for it. It'd probably be a
massive waste of time though, in the larger scale of things.

[Trevor]

"C# Learner" <cs****@learner.here> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...

Daniel Pratt wrote:

Hi C# Learner,

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

No language that I've encountered would I consider perfect.

I feel the same :-)

Not even
close. Any language that I've seen is either filled with compromises or is practically useless (or both). Have you found a language you like better, or are you considering another vocation?

I've been a Delphi person for some years. Delphi's a language that, I
feel, makes writing clear code easy, and writing hard-to-read code
difficult. With that said, I don't feel Delphi is perfect.

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(

C# is a nice language in some ways, but it's too inhibited by
C/C++/Java, IMO.

I think that the ideal language would combine the best parts of C# and
Delphi.

I may, at some point in the future, design such a language mainly for
fun, and perhaps even make an MSIL compiler for it. It'd probably be a
massive waste of time though, in the larger scale of things.

"Different strokes for different folks". While you find Delphi readable
and C style (based on C syntax - i.e., C, C++, Java, C#) code unreadable, I
find Delphi code unreadable. There isn't much you can do except find a
language that you are comfortable with and stick to it.

[Max Power]

C# Learner <cs****@learner.here> wrote in news:#g9rpoAHEHA.2576
@TK2MSFTNGP11.phx.gbl:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

Actually, C#/C++/Java were developed by nerds. The real problem is nerds,
not MS. ;-)

[Kevin P. Fleming]

C# Learner wrote:

For clarification, the difference with Delphi's returning mechanism is
that there's no need to declare the result variable, and no need to use
'return result;'.

So how then do you exit "early" from a function, if you have checked
input arguments and decided you already know the result without further
processing? Is your only choice to wrap the entire rest of the function
body inside an else block? If so, the code gets very unreadable very
quickly, especially if there multiple possible early exit points from
the function.

[Jon Skeet [C# MVP]]

C# Learner <cs****@learner.here> wrote:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

So use VB.NET instead - there's very little not to, if you don't like C
style syntax.

Why get annoyed by a language (and moan in an unconstructive way to
those who *do* like it) when there's a perfectly viable alternative?

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).
Isn't it a good thing that each of us can have a language which works
the way we want?

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

[C# Learner]

Kevin P. Fleming wrote:

C# Learner wrote:

For clarification, the difference with Delphi's returning mechanism is
that there's no need to declare the result variable, and no need to
use 'return result;'.

So how then do you exit "early" from a function, if you have checked
input arguments and decided you already know the result without further
processing? Is your only choice to wrap the entire rest of the function
body inside an else block? If so, the code gets very unreadable very
quickly, especially if there multiple possible early exit points from
the function.

One can exit early if one so chooses, using 'Exit'.

i.e.:

function Foo: Boolean;
begin
Result := True;
if FooBar then
Exit;
//...
end;

Personally, I don't like exiting before the end ever. If the routine is
so complicated that you need to return before the end to avoid a code
mess, I think it needs refactoring. Perhaps my opinion on this is
somewhat biased, though, due to this being a style I've practised for a
long time.

[Daniel O'Connell [C# MVP]]

"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...

C# Learner wrote:

Julie wrote:

> I'll take the language any day. It is their sucky, buggy, deficient
> IDE that
> gets my goat, day after day.
>
> So far, their IDE can handle "hello world" class projects, but not much
> more...
The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.

I'm currently working on one solution composed of maybe 30-40 projects of
C#,
managed C++, and native C++, with multiple forms, controls, etc.

It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a debugging
pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.

Try closing the IDE and deleting the .suo file. This sounds like a known bug
that has been cropping up for quite some time(I seem to recall filing a bug
report myself), there is hope it will be fixed in whidbey, but I don't know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.

Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.

[Kevin P. Fleming]

C# Learner wrote:

Personally, I don't like exiting before the end ever. If the routine is
so complicated that you need to return before the end to avoid a code
mess, I think it needs refactoring. Perhaps my opinion on this is
somewhat biased, though, due to this being a style I've practised for a
long time.

Everyone has their own opinions, but think of a simple situation: you're
writing some sort of text parser, and you need a function to take a
token parsed from the file and turn it into an integer value for use
elsewhere in the program. There are many different tokens, of varying
lengths, but they are all known at compile time.

int ParseToken(string token)
{
if (token.Length == 0)
return 0;

switch (token)
{
case "A":
return 1;
case "B":
return 2;
default:
break;
}

if (token.Length < 2)
return 0;

switch (token)
{
case "M1":
return 23;
case "M2":
return 25;
default:
break;
}

etc.
}

Without early returns, this code becomes extremely difficult to read due
to many levels of indentation and extra blocks. Breaking it up into
multiple functions to avoid that would be silly, as it's so simple.
Avoiding the early returns as a matter of "style" causes the code to be
less efficient, as it will continue trying to compare the token against
strings it could never match (granted the compiler may be smart enough
to help out here, or it may not).

[C# Learner]

Kevin P. Fleming wrote:

[...]

Without early returns, this code becomes extremely difficult to read due
to many levels of indentation and extra blocks. Breaking it up into
multiple functions to avoid that would be silly, as it's so simple.

To be honest, I find the following slight modification which doesn't
return early, much easier to read:

int ParseToken(string token)
{
int result = 0;

if (token.Length > 0)
{
if (token.Length == 1)
{
switch (token)
{
case "A":
result = 1;
case "B":
result = 2;
default:
break;
}
}
else
{
switch (token)
{
case "M1":
result = 23;
case "M2":
result = 25;
default:
break;
}
}
}

etc.

return result;
}

Again, this may just be due to what *I* am used to doing.

<snip>

Regards

[C# Learner]

Jon Skeet [C# MVP] wrote:

C# Learner <cs****@learner.here> wrote:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.
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 :-P

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 :-P

[Reginald Blue]

C# Learner wrote:

I've been a Delphi person for some years. Delphi's a language that, I
feel, makes writing clear code easy, and writing hard-to-read code
difficult. With that said, I don't feel Delphi is perfect.

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(

The one nice thing about .NET is that it allows for you to code in
"Delphi.NET" and someone to use your work in C# or whatever.

FYI:

http://www.gotdotnet.com/team/lang/

Lists all of the .NET languages that people are working on.

Supposedly here is the pascal work:

http://www.citi.qut.edu.au/research/...entPascal.html

But their web site doesn't respond.

There may be one other Pascal.NET project out there somewhere.

Just promise us that you won't start coding in Cobol.NET.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Jon Skeet [C# MVP]]

C# Learner <cs****@learner.here> wrote:

<snip>

So one can choose either readability or consistency, but not both.
I don't believe that's true.
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!

Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. However, you can easily make C# behave
like Delphi in that respect, to a large extent. Just declare:

FontTagElement result;
at the top of the method

and

return result;

at the end.

Personally the first thing I'd ditch from the above is the K&R
bracing...

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

[Chris A. R.]

// Here is a *Very* common C/C++ pattern used for returning a
// value in a single place withing a method. If you prefer this kind of
// readability, then go ahead and use it. But you won't be unique in
this.

FontTagElement GetFontTagElement()
{
FontTagElement result;
//...

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;
}
return result;
}

Chris A.R.

"C# Learner" <cs****@learner.here> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...

Jon Skeet [C# MVP] wrote:

C# Learner <cs****@learner.here> wrote:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

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 :-P

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 :-P

[Frank Lesser [LSW]]

"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:u6**************@TK2MSFTNGP09.phx.gbl...

Hi C# Learner,

"C# Learner" <cs****@learner.here> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
No language that I've encountered would I consider perfect. Not even
close. Any language that I've seen is either filled with compromises or is
practically useless (or both). Have you found a language you like better,

or are you considering another vocation?

Regards,
Daniel

Hi and sorry but I have to add here some hints to my favorite language:
Smalltalk.
Smalltalk is pure OO and source-code readability is superior. It is
dynamically typed so type declarations are not necessary - it uses keyword
messages
aMessageBox titled: 'I have had enough' confirm: 'Do you like
Smalltalk?' onYes: [ Transcript show: 'read further'; cr ]
instead of
aMessageBox.Show( "'Do you like Smalltalk?", "'I have had enough'
confirm" ... );
Unfortunaltley major Smalltalk didn't integrate well in the past into the
Windows OS - VisualWorks / IBM VA have their own philospohy about using the
native OS
IBM VAST uses a Motif layer and VisualWorks emulated widgets.

Dolphin ( www.object-arts.com ) is a nice Windows-Smalltalk with a nice
Windows integration.
Smallscript is an ongoing work to integrate Smalltalk with .NET

We have created our own - still proprietary Smalltalk which has also a deep
OS Integration.
It is not easy to integrate Smalltalk with .NET - Traditionally Smalltalk
dialects have their own Virtual-Machine incl. JIT. CLR is too limited in
many ways to run Smalltalk
effectifley on it. David Simmons ( www.smallscript.org ) who was in the
design team of .NET is creating with S# for .NET.

Be carefull - if you enter the world of Smalltalk programming you will
probably never like to go back - which means today swiming against the
mainstream.

Regards, Frank Lesser, www.lesser-software.com

[Tim Jarvis]

C# Learner wrote:

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;
}
}

Maybe I'm missing something here, but wouldn't the addition of just a
couple of lines of code, give you the intermediate Result variable and
the readability that you want.

I.e.

FontTagElement Result = null;
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);
}
}
return Result;

Rgds Tim.

[Tim Jarvis]

Chris A. R. wrote:

// Here is a Very common C/C++ pattern used for returning a
// value in a single place withing a method. If you prefer this
kind of // readability, then go ahead and use it. But you won't
be unique in this.

FontTagElement GetFontTagElement()
{
FontTagElement result;
//...

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;
}
return result;
}

Chris A.R.

LOL.....snap.

[Tim Jarvis]

Tim Jarvis wrote:

Maybe I'm missing something here, but wouldn't the addition of just a
couple of lines of code, give you the intermediate Result variable and
the readability that you want.

I.e.

FontTagElement Result = null;
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);
}
}
return Result;

Rgds Tim.

Although, please excuse the brain dead casing.... :-(

[C# Learner]

Jon Skeet [C# MVP] wrote:

[...]
Personally the first thing I'd ditch from the above is the K&R
bracing...

Well, I have tried the other style (can't remember how it's termed...)
and it is my opinion that the K&R style makes code more readable, as it
places less emphasis on the individual blocks of code.

I'm not expecting everyone to share this viewpoint; I'm merely
expressing it.

I think the K&R bracing style is like Marmite -- you either love it or
you hate it :-)

[Tom]

After reading your response, Mr C# Learner, I'm convinced you're smoking
crack. I don't find any of your code snippets to be particularly readable
nor significantly different nor unusable in current C#. I don't happen to
like your layout choices as far as brackets, but your either of your first
two layout choices would work.

You are, of course always at liberty to switch to Delphi.NET. However, my
advice would be to refrain from commenting about your perceived detriments
in C# in a C# newsgroup.

Tom
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

C# Learner <cs****@learner.here> wrote:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

So use VB.NET instead - there's very little not to, if you don't like C
style syntax.

Why get annoyed by a language (and moan in an unconstructive way to
those who *do* like it) when there's a perfectly viable alternative?

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).
Isn't it a good thing that each of us can have a language which works
the way we want?

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

[Tim Jarvis]

C# Learner wrote:

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(

What does that mean ? "Global data/routines", curious is all.

For what it is worth, I hold the same opinion as you, in that I don't
think that there is a perfect .NET language out there.

I guess I am lucky in that I have 5 .NET languages (and their IDE's) on
my desktop, actually 6 if you count ILASM. 3 of those I know quite well
and 2 I don't use much, but have on occasion. (see who can name the 5)

I think it comes down to personal preference, and to be frank, unless
as you say, you are willing to roll your own, if you want to do .NET
coding, you will just have to choose one (or mix them) that will get
the job done.

Cheers Tim.

[Philip Rieck]

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.

Like edit and continue? VB.net got there first, after the CLR put in
support.

Like Generics? Both languages have support.

Like named indexers? VB has had it from the beginning.. C# still doesn't.

I'd disagree completely with the fact that C# is *the* language. I prefer
it in most cases, but that's no gague of which language is "it". .net is
specifically designed so that no one language is "it"..... other than MSIL.
And in fact no one language can utilize all capabilities of the CLR (other
than IL.)

I also disagree with the industry. Many places are going VB.NET because of
the number of VB and ASP developers they are retraining.
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.
[...snip, as it's not's important]
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!

Why not do this yourself? put "return result" at the end, as many people
would recommend you do anyway? (In fact, many would say that you have much
too much control flow in this one function anyway) C# lets you do this, but
doesn't treat "result" as a keyword. Its sparseness of keywords is a
feature, if you ask me --- not a problem.

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 :-P

So create one. The compiler services in the FCL are more than adequate.

[C# Learner]

Jon Skeet [C# MVP] wrote:

[...]
Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. [...]

Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?

Here're the top two again:

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;
}
}

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;
}

[C# Learner]

Philip Rieck wrote:

[...]

That sounds great. If I ever believe to have found such a language,
I'll be sure to let the group know :-P

So create one. The compiler services in the FCL are more than adequate.

A problem I see here with creating a new language is that I'd probably
also want to create an IDE for it, if I were looking to use the language
to write GUI applications in, using a form designer.

That'd make it:

- design language;
- create compiler; and
- create IDE.

I'd imagine creating an IDE for it would be extremely time-consuming.

[C# Learner]

Reginald Blue wrote:

C# Learner wrote:

I've been a Delphi person for some years. Delphi's a language that, I
feel, makes writing clear code easy, and writing hard-to-read code
difficult. With that said, I don't feel Delphi is perfect.

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(

The one nice thing about .NET is that it allows for you to code in
"Delphi.NET" and someone to use your work in C# or whatever.

FYI:

http://www.gotdotnet.com/team/lang/

[...]

Interesting, thanks!

[Jon Skeet [C# MVP]]

C# Learner <cs****@learner.here> wrote:

Jon Skeet [C# MVP] wrote:

[...]
Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. [...]

Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?

I think I'd use the first one, with the else clause. However, I'd
recode the first part to:

if (length==SingleElementPartCount)
{
string name = arr[FirstIndex];
if (name==FontNameSpecifier)
{
return new FontTagElement(name);
}
else
{
int size = TryStringToInt(name);
return new FontTagElement(size);
}
}

etc

In fact, I'd probably end up declaring name right at the top, as it's
such a common expression in your code.

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

[C# Learner]

Tim Jarvis wrote:

C# Learner wrote:

I'm thinking of giving Delphi 8 (for .NET) a spin. Though there is a
problem with that (IMO): it allows global data/routines :(
What does that mean ? "Global data/routines", curious is all.

Meaning that one can create global variables and routines (procedures or
functions) in the way that one can in C++, for example.

i.e.:

void Foo() // global, declared outside of a class
{
}

class Class
{
void Foo() // non-global - a member of a class
{
}
}
For what it is worth, I hold the same opinion as you, in that I don't
think that there is a perfect .NET language out there.

I guess I am lucky in that I have 5 .NET languages (and their IDE's) on
my desktop, actually 6 if you count ILASM. 3 of those I know quite well
and 2 I don't use much, but have on occasion. (see who can name the 5)

I think it comes down to personal preference, and to be frank, unless
as you say, you are willing to roll your own, if you want to do .NET
coding, you will just have to choose one (or mix them) that will get
the job done.

[C# Learner]

Chris A. R. wrote:

// Here is a *Very* common C/C++ pattern used for returning a
// value in a single place withing a method. If you prefer this kind of
// readability, then go ahead and use it. But you won't be unique in
this.

FontTagElement GetFontTagElement()
{
FontTagElement result;
//...

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;
}
return result;
}

Hi Chris,

Yes, this is what I often do, but I get blasted by C# gurus for doing
this, who tell me, "This is C#, not Delphi!"

For clarification, the difference with Delphi's returning mechanism is
that there's no need to declare the result variable, and no need to use
'return result;'.

[microsoft.public.dotnet.languages.csharp]

> I also disagree with the industry. Many places are going VB.NET because o

the number of VB and ASP developers they are retraining

terrible. generally speaking, I'd have more faith in Java & C developers than VB and ASP people. having experienced frustration of working with these VB and ASP people.

[Marcin Grzêbski]

Max Power wrote:

C# Learner <cs****@learner.here> wrote in news:#g9rpoAHEHA.2576
@TK2MSFTNGP11.phx.gbl:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

Actually, C#/C++/Java were developed by nerds. The real problem is nerds,
not MS. ;-)

"Very nice" *NERDS* definitions :)

http://www.urbandictionary.com/define.php?term=nerd&f=1
http://www.hyperdictionary.com/search.aspx?define=nerd
http://www.computeruser.com/resource...ml?lookup=2995

Marcin

[C# Learner]

Jon Skeet [C# MVP] wrote:

C# Learner <cs****@learner.here> wrote:

Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?
I think I'd use the first one, with the else clause.

Okay.
However, I'd recode the first part to:

if (length==SingleElementPartCount)
{
string name = arr[FirstIndex];
if (name==FontNameSpecifier)
{
return new FontTagElement(name);
}
else
{
int size = TryStringToInt(name);
return new FontTagElement(size);
}
}

etc

In fact, I'd probably end up declaring name right at the top, as it's
such a common expression in your code.

Oops, yes! Looking back on it, I can't've been fully awake when I wrote
that method :-)

Regards,
Tom

[Tim Jarvis]

C# Learner wrote:

Tim Jarvis wrote:
Meaning that one can create global variables and routines (procedures
or functions) in the way that one can in C++, for example.

i.e.:

void Foo() // global, declared outside of a class
{
}

class Class
{
void Foo() // non-global - a member of a class
{
}
}

I guess this just shows the language's heritage, in fact just like C++,
Delphi is not a "pure" oo language as it is an evolution from pascal (
like C++ is from C )

note, you don't have to write those non class/object routines though ;-)

Rgds Tim.

[Tim Jarvis]

C# Learner wrote:

For clarification, the difference with Delphi's returning mechanism
is that there's no need to declare the result variable, and no need
to use 'return result;'.

It is important to note though, In Delphi the variable is actually
implicitly declared in every function and only when you have the
extended syntax enabled ($X+) although it is true this is the default,
so many programmers may not even realise that they have the extended
syntax on.

I said in another thread about how language preferences are a very
subjective thing, this feature that you miss in C#, is exacly the thing
that a guy I used to work with hated in Delphi, he hated the fact that
a variable was being declared for him in a hidden way...I must admit, I
haven't even given it a second thought in C#, I just accepted the C#
way of doing things, personally this type of issue for me is a very
minor thing, The thing that sometimes slows me down is I still find
myself thinking about doing things in the "Delphi way", but to be
honest this is more a VCL v's .NET framework thing rather than a
language thing in most cases.

Rgds Tim.

[Julie]

C# Learner wrote:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

I'll take the language any day. It is their sucky, buggy, deficient IDE that
gets my goat, day after day.

So far, their IDE can handle "hello world" class projects, but not much more...

[C# Learner]

Tim Jarvis wrote:

C# Learner wrote:

Tim Jarvis wrote:

Meaning that one can create global variables and routines (procedures
or functions) in the way that one can in C++, for example.

i.e.:

void Foo() // global, declared outside of a class
{
}

class Class
{
void Foo() // non-global - a member of a class
{
}
}

I guess this just shows the language's heritage, in fact just like C++,
Delphi is not a "pure" oo language as it is an evolution from pascal (
like C++ is from C )

Also, I think some "old-school" Delphites might still want to use global
data/routines, and, secondly, this feature would seemingly help for when
converting to Delphi 8 code from older Delphi code.
note, you don't have to write those non class/object routines though ;-)

I guess I'm just concerned that if it's possible, lots of people will do
it :-) If there's a way, there's a will ;-))

Regards

[C# Learner]

Julie wrote:

I'll take the language any day. It is their sucky, buggy, deficient IDE that
gets my goat, day after day.

So far, their IDE can handle "hello world" class projects, but not much more...

The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

[C# Learner]

Reginald Blue wrote:

[...]
Just promise us that you won't start coding in Cobol.NET.

Well, I've never touched Cobol, so I can't appreciate how horrible it
might be, but I can tell you for certain that I'd never remotely
consider using Fortran! :-)

[Frans Bouma [C# MVP]]

C# Learner <cs****@learner.here> wrote in news:#g9rpoAHEHA.2576
@TK2MSFTNGP11.phx.gbl:

I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.

C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.

Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.

You could always use VB.NET, if you like its constructs better. No-
one is forcing you to use just C#, as VB.NET can do what you want too.
(except a little operator overloading limitations here and there...)

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Julie]

C# Learner wrote:

Julie wrote:

I'll take the language any day. It is their sucky, buggy, deficient IDE that
gets my goat, day after day.

So far, their IDE can handle "hello world" class projects, but not much more...

The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.

I'm currently working on one solution composed of maybe 30-40 projects of C#,
managed C++, and native C++, with multiple forms, controls, etc.

It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a project
because somewhere else the IDE has a file open (in this case, a debugging pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.

A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.

[Kevin P. Fleming]

C# Learner wrote:

For clarification, the difference with Delphi's returning mechanism is
that there's no need to declare the result variable, and no need to use
'return result;'.

So how then do you exit "early" from a function, if you have checked
input arguments and decided you already know the result without further
processing? Is your only choice to wrap the entire rest of the function
body inside an else block? If so, the code gets very unreadable very
quickly, especially if there multiple possible early exit points from
the function.

[C# Learner]

Kevin P. Fleming wrote:

C# Learner wrote:

For clarification, the difference with Delphi's returning mechanism is
that there's no need to declare the result variable, and no need to
use 'return result;'.

So how then do you exit "early" from a function, if you have checked
input arguments and decided you already know the result without further
processing? Is your only choice to wrap the entire rest of the function
body inside an else block? If so, the code gets very unreadable very
quickly, especially if there multiple possible early exit points from
the function.

One can exit early if one so chooses, using 'Exit'.

i.e.:

function Foo: Boolean;
begin
Result := True;
if FooBar then
Exit;
//...
end;

Personally, I don't like exiting before the end ever. If the routine is
so complicated that you need to return before the end to avoid a code
mess, I think it needs refactoring. Perhaps my opinion on this is
somewhat biased, though, due to this being a style I've practised for a
long time.

[Daniel O'Connell [C# MVP]]

"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...

C# Learner wrote:

Julie wrote:

> I'll take the language any day. It is their sucky, buggy, deficient
> IDE that
> gets my goat, day after day.
>
> So far, their IDE can handle "hello world" class projects, but not much
> more...
The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.

How about a deal: you take the language and I take the IDE ;-P

Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.

I'm currently working on one solution composed of maybe 30-40 projects of
C#,
managed C++, and native C++, with multiple forms, controls, etc.

It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a debugging
pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.

Try closing the IDE and deleting the .suo file. This sounds like a known bug
that has been cropping up for quite some time(I seem to recall filing a bug
report myself), there is hope it will be fixed in whidbey, but I don't know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.

Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.

[Kevin P. Fleming]

C# Learner wrote:

Personally, I don't like exiting before the end ever. If the routine is
so complicated that you need to return before the end to avoid a code
mess, I think it needs refactoring. Perhaps my opinion on this is
somewhat biased, though, due to this being a style I've practised for a
long time.

Everyone has their own opinions, but think of a simple situation: you're
writing some sort of text parser, and you need a function to take a
token parsed from the file and turn it into an integer value for use
elsewhere in the program. There are many different tokens, of varying
lengths, but they are all known at compile time.

int ParseToken(string token)
{
if (token.Length == 0)
return 0;

switch (token)
{
case "A":
return 1;
case "B":
return 2;
default:
break;
}

if (token.Length < 2)
return 0;

switch (token)
{
case "M1":
return 23;
case "M2":
return 25;
default:
break;
}

etc.
}

Without early returns, this code becomes extremely difficult to read due
to many levels of indentation and extra blocks. Breaking it up into
multiple functions to avoid that would be silly, as it's so simple.
Avoiding the early returns as a matter of "style" causes the code to be
less efficient, as it will continue trying to compare the token against
strings it could never match (granted the compiler may be smart enough
to help out here, or it may not).

[C# Learner]

Kevin P. Fleming wrote:

[...]

Without early returns, this code becomes extremely difficult to read due
to many levels of indentation and extra blocks. Breaking it up into
multiple functions to avoid that would be silly, as it's so simple.

To be honest, I find the following slight modification which doesn't
return early, much easier to read:

int ParseToken(string token)
{
int result = 0;

if (token.Length > 0)
{
if (token.Length == 1)
{
switch (token)
{
case "A":
result = 1;
case "B":
result = 2;
default:
break;
}
}
else
{
switch (token)
{
case "M1":
result = 23;
case "M2":
result = 25;
default:
break;
}
}
}

etc.

return result;
}

Again, this may just be due to what *I* am used to doing.

<snip>

Regards

[Jon Skeet [C# MVP]]

C# Learner <cs****@learner.here> wrote:

<snip>

So one can choose either readability or consistency, but not both.
I don't believe that's true.
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!

Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. However, you can easily make C# behave
like Delphi in that respect, to a large extent. Just declare:

FontTagElement result;
at the top of the method

and

return result;

at the end.

Personally the first thing I'd ditch from the above is the K&R
bracing...

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

[Chris A. R.]

It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers are
much more likely to have a clue on how to write working code in a Threaded
environment. I also find that most VB programmers don't understand the
windows messaging architecture, whereas most C/C++ programmers do
understand.

Of course, there are dud C/C++ programmers, but understanding the foundation
of the windows architecture is important for complex programs. So, as lead
engineer and architect at the company I work for, pointy haired boss and
all, I prefer people with C/C++ experience.

Chris A.R.

"microsoft.public.dotnet.languages.csharp"
<an*******@discussions.microsoft.com> wrote in message
news:A3**********************************@microsof t.com...

I also disagree with the industry. Many places are going VB.NET because of > the number of VB and ASP developers they are retraining.

terrible. generally speaking, I'd have more faith in Java & C

developers than VB and ASP people. having experienced frustration of
working with these VB and ASP people.