Smithers said:
You can all just ignore Mark Rae. He has a long history in these NGs for
being irrational and emotional...
Hmmm...maybe he doesn't post in the C# newsgroup much? I hadn't noticed him
as being one of the "usual suspects". Oh well...maybe that's the risk of
cross-posting like you did.
[...]
Rather than letting Mark derail this thread, I certainly would have
appreciated a few more ideas for what you all are *actually* doing for
your naming conventions currently.
Well, if that's so then I'd suggest you might have been more clear in your
original post about that. I certainly didn't get the impression that you
wanted personal coding habits, and as near as I can tell the question you
actually asked has been answered already.
I guess this is another case where people don't really want to say what
they *actually* do because of emotional guys like Mark Rae criticizing.
No, it's just another case of a person asking a different question than the
one they really want the answer to. I'm perfectly comfortable with my
naming conventions, even as they continue to be revised over time in
response to a variety of factors, including who I'm coding with, what
language I'm using, and what mood I'm in when I start a project. It
wouldn't bother me at all for someone to criticize something like the naming
convention I use when coding.
As far as what I actually do in C#, I don't have a good answer, as I've only
been doing C# stuff for a year. It's way too early for me to have developed
any solid philosophies on naming conventions specifically for .NET. As it
happens, I do like and use Hungarian and so much of the conventions I use
doing C# code is based on that. Initially, I *only* used Hungarian but then
as I started inheriting from existing .NET classes, that started to result
in some less-than-pleasant-looking juxtapositions where my own methods and
properties showed in various places next to the .NET-style ones.
So lately I've been experimenting with conforming more closely to the .NET
style when writing properties and methods. For the methods, the main
difference here is I have switched from using "F" as the first letter in a
method that returns a boolean value to using the "Is" construct, because
inclusion of the "Is" still makes it clear that I'm dealing with a boolean.
For other methods that return a value, I continue to use the Hungarian-style
notation to ensure that the type return value is clearly noted in the method
name. For properties, I have taken to sticking with a simple descriptive
name rather than including any type information, and for any methods that
are implementing functionality that already has a standard naming convention
within .NET (Dispose, Close, OnPaint, etc.) I use the .NET standard even
when it's not strictly necessary (obviously in some cases there's no
choice).
Within a class, I continue to use Hungarian. Field names, variables,
parameters, etc. all get Hungarian style type tags and suffixes (Min, Mac,
Cur, etc.). And I use the convention of putting an underscore to start the
name of any non-public entity.
As far as the type tags go, to a certain extent my use of Hungarian is
simply so that I don't get out of the habit. One of the primary arguments
in favor of Hungarian comes from languages like C or C++ where you may have
defined types that are simply duplicates of some existing built-in type. In
the absence of strict type checking, Hungarian allows one to review the code
and more easily detect type mis-matches. Even in .NET/C# this still comes
up though. For example, I use "x", "dx", and "cx" as variations on an
x-coordinate for a type tag, each with their own specific meaning (absolute
coordinate; delta, always used in relation to some absolute; and a count,
respectively). This is because there's no coordinate type; everything still
uses ints and so there is still the potential for a semantic type mis-match
that the compiler doesn't catch.
But mostly, C# is a very strongly typed language and so there's not really
as much need to worry about mismatching types as the compiler simply won't
let you do it. So I'd admit that in most cases, the Hungarian notation
doesn't serve any purpose. Of course, since it does still serve a purpose
in some very narrow-but-common situations, and since mixing Hungarian and
non-Hungarian doesn't look very nice (and is also prone to errors), that is
in and of itself a justification for using Hungarian.
You'll note that none of the above has anything to do with naming a class.
On that topic...
The "flavor" of Hungarian that I originally used involved coming up with
three- or four-letter names for types (with a comment with the type
declaration explaining the abbreviation). The actual type would be
upper-case while the type tag would be exactly the same except lower case.
This was really nice for coming up with and interpreting type tags, but you
often got a lot of similar-looking types, and anything that wasn't
ubiquitous in code risked being misunderstood.
It did have the advantage though that types and variable names were short
and easy to type. It kept the code nice and concise, and it was much
quicker to type code in.
Now with Visual Studio's context-sensitive typing expansion
("intellisense"?), the fact that a type name is lengthy doesn't slow me down
since I almost never have to type the whole thing out anyway (I get really
annoyed when I have to do something in C++ now and don't have the code
editor filling things in for me
). So where I used to write something
like:
typedef class DataPerClient
{
...
} DPC, *PDPC, **PPDPC;
using the DPC, PDPC, and PPDPC for declarations and the lower-case versions
for the actual variable, I now just use the "DataPerClient" typename in C#
(and of course, since the concepts of pointers and pointers to pointers has
been covered with a veneer enforced by the language, I don't bother with
anything but the base type in C#). I also don't include base type
information if it's reasonably clear from the name of the class what the
base type or intended variant (such as the "XyzForm is modeless, XyzDialog
is modal" convention) is (which, though I didn't realize it initially, turns
out to be acceptable under the .NET naming guidelines).
Note the initial capital letters, lower-case for each individual word in the
class name. I was using that for my class names long before .NET showed up,
and it's been a fairly common convention for that time as well. It's not
much of a surprise that the .NET guidelines recommend the same thing.
So, does *that* answer the question you meant to ask?
Pete
