I've Had Enough

[Tim Jarvis]

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]

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]

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]

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]

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]

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

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]

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]

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

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]

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]

[...]

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

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

 

[Frank Lesser [LSW]]

Hi C# Learner,



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

 

[C# Learner]

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

 

[C# Learner]

[...]
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;
}

 

[Jon Skeet [C# MVP]]

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

 

[=?ISO-8859-2?Q?Marcin_Grz=EAbski?=]

@TK2MSFTNGP11.phx.gbl:





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/resources/dictionary/definition.html?lookup=2995

Marcin

 

[C# Learner]

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

 

[Frans Bouma [C# MVP]]

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