January 5, 2006

A T for my TClasses

Delphi naming convention is to use a T in front of types. Not so in the .NET FCL and this can be confusing.

I've always liked Delphi's naming convention, but wasn't really sure if there weren't better options in other libraries. At first sight, .NET class library habit of using plain class and types names seems more readable. But I've recently found a very strange situation where the lack of a good convention stands out, for the worse.

Here goes the example. A Form in WinForms has a DialogResult property (corresponding to Delphi's ModalResult property). This is an enumerated value of type DialogResult. Yes, the property name and its type name are identical. You disambiguate the first by prefixing it with self (a common practice in C# that I do not like) and the second by prefixing it with the full namespace name:

self.DialogResult := System.Windows.Forms.DialogResult.OK;

If you fail to spell out the second, the compiler will stop with an error. It is even worse that if inside any method of a form you call MessageBox.Show and check the result (again of type DialogResult) you end up referring to the property, not the the type, unless you specify the full namespace. Needless to say, I find this annoying. This situation is fairly frequent in the FCL library, but the fault is not on the specific property or type names. The fault is on the type naming convention (or the lack of it) in the library. So let's keep our TClasses in Delphi and be happy with them.



A T for my TClasses 

that's one of the things I don't like about C# where 
I think they should've copied Delphi

however, in Delphi it annoys me that you have to use 
& to use reserved words as normal identifiers =o(
Comment by Eber Irigoyen [http://ebersys.blogspot.com] on January 5, 01:17

T is good, even if it is the initial letter of Trouble :-) 

I totally agree with you, Marco.

Recently, I read a book about .NET architecture and C#

I perfectly remember about a paragraph talking about
conventions in naming types and identifiers: it says
that prefixing classes names with a letter is a bad
habit because the meaning of a type, and what kind of
type it is (class, enumeration and so on...) should be
deduced from the full name itself, without the need to
use that "ugly" prefix convention.

After reading that sentence, I have turned the page
and found the explanation of...IDisposable.
So what's that "I"? :-)

Joking aside, I often found myself using the same
"name" for a property and the data type it belongs to,
so the "T" prefix let me remove the ambiguity in a
breeze, with no effort, but without abusing of them.

I warmly hope to code these "T" for a long time... :-)
Comment by Marco Breveglieri [http://www.marco.breveglieri.name] on January 5, 03:18

To Eber 

Eber, I think you're right about the fact that C#
creators should have copied from Delphi. :-)
Maybe they had even thought about that before.

However, from Microsoft point of view, I am sure that
"no-T convention" is the right option because it makes
C# look more similar to Java (so Java developers can
migrate to .NET easily) and - on the VB.NET side - it
ensures a higher compatibility with ActiveX control
names, aiding VB developers to port their existing
projects and develop new ones.

I think the "T lack" is not a pure matter of code
elegancy; in fact, interfaces are "I" prefixed (but
they were already expressed with that convention in
the "COM era", so it doesn't hurts Visual Studio and
COM developers).

In my opinion, the "&" prefix doesn't bother you so
much once you get used to it. :-)
Comment by Marco Breveglieri [http://www.marco.breveglieri.name] on January 5, 17:10

A T for my TClasses 

 I see where you are coming from Marco but I never 
have this problem using C# and Visual Studio. 

I always write it like :

DialogResult = DialogResult.OK;

-- Robert
Comment by Robert Kozak [http://TheArtOfProgrammingWith.Net] on January 5, 19:24

A T for my TClasses 

Delphi has type equivalence. Therefore, it is 
possible to declare T prefixed equivalents for 
any .NET type, put them in a dedicated assembly (that 
is required at compile time only) and forget 
about .NET case sensitive oriented naming convention.
For details: 
This program (source included) is a not trivial 
example of use of this technique
Comment by Mauro Venturini on January 5, 21:08

A T for my TClasses 

"However, from Microsoft point of view, I am sure that
"no-T convention" is the right option because it makes
C# look more similar to Java (so Java developers can
migrate to .NET easily)"

that's exactly my thinking, but I was thinking they 
tryied to make C# more C,C++"ish", but I guess 
Java"ish" as well, if they would've gone with 
the "T", it would've been more obvious all the 
inheritance that C# has from Delphi, but this way, 
very few people are aware of this fact and people are 
more comfortable that C# is an "extension" to their 
current language, I've noticed people are very 
surprised when I tell them "this or that feature came 
from Delphi"
Comment by Eber Irigoyen [http://ebersys.blogspot.com] on January 5, 22:25

A T for my TClasses 

 Thanks Marco!!!

I'm new to delphi DOT net and I've been battling with 
dialogresult!!! I eventually got it working when 
prefixed with the namespace, but I had no idea what 
was going on.

Thanks for the explanation.
Comment by Trevor on April 30, 11:58

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.