The effects of .Net on standards/conventions.

[Paul Mc]

G'day all.

I was just mucking about with visual inheritance last night, and it got me
thinking about standards and conventions.

The way I see it is that vb.net makes it very easy to maintain what I will
call "output standards" - ie the basic look/feel & baseline behaviour of
your typical UI app/components. Visual (and indeed non-visual) inheritance
is a powerful tool in this regard, IMO.

Under the bonnet, however, things are a little different. There was a post
(by Sam Spencer I believe) a while back, which mentioned in passing that
MS no longer encouraged the use of the hungarian-style naming convention
for .Net - apparently because the mouse-over defininition-tooltip thingy
made it unnecessary.

Personally, I thought "blow that!" - I do not want to have to pause my mouse
over a var, or go to the declaration to see what the var is exactly. I like
the hungarian because I know strSomething is (probably) a string, at first
glance.

Now I have spent a lot more time in VB.Net, written a lot more code in it,
and I am beginning to see the point, a little. There are so many different
types that you could declare - true, many are of the same basic type, ie
all the different specific types of exception that you can Catch - but it
makes me wonder about the continued value of the "Prefix Everything" kind
of naming convention. It may be that it is easier/quicker to pause the mouse
over, or look at the declaration of, a var to see what it is exactly.

I guess that personally, I will continue naming basic vars - strings, etc-
as always (though the numerics will be a headache! int32Loop instead of intLoop?
Blech! But I would like to get away from the int/long stuff). Then with the
less basic types of object -the exceptions, the collections, etc etc - I
will be using a convention based on their generic type. For example, colSomeCollection
for a collection regardles of whether it is a StringCollection or an ObjectCollection
or an XXXCollection and so on...

Any thoughts?
Cheers,
Paul

[Ed Courtenay]

I used to be of the opinion that hungarian notation was the best way of
describing the contents of a variable, but after a few years developing
outside the MS loop (Java) I've changed my mind.

In essence, as far as I understand it, hungarian notation was adopted due to
the way that C/C++ allows the programmer to throw around variables and
pointers, and that it is often hard to find the declaration of that variable
(which .c, .cpp or .h file is it defined in?), so names like lpszName (long
pointer to a zero terminated string) was incredibly useful.

With OO based languages such as Java, VB.NET or C# this becomes less
important; the mindset changes from 'what exactly is this; a pointer or a
variable?' to 'here's an object; deal with it'.

There are others out there who've expressed this idea much better than I;
I'd suggest that you look at Tom Archers' "Inside C#" (Microsoft Press) - I
know, I know this is a VB.NET newsgroup, but a lot of the ideas in this tome
can very easily be translocated in to the VB.NET arena.



"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3b131b8d@news.devx.com...
>
> G'day all.
>
> I was just mucking about with visual inheritance last night, and it got me
> thinking about standards and conventions.
>
> The way I see it is that vb.net makes it very easy to maintain what I will
> call "output standards" - ie the basic look/feel & baseline behaviour of
> your typical UI app/components. Visual (and indeed non-visual) inheritance
> is a powerful tool in this regard, IMO.
>
> Under the bonnet, however, things are a little different. There was a post
> (by Sam Spencer I believe) a while back, which mentioned in passing that
> MS no longer encouraged the use of the hungarian-style naming convention
> for .Net - apparently because the mouse-over defininition-tooltip thingy
> made it unnecessary.
>
> Personally, I thought "blow that!" - I do not want to have to pause my
mouse
> over a var, or go to the declaration to see what the var is exactly. I
like
> the hungarian because I know strSomething is (probably) a string, at first
> glance.
>
> Now I have spent a lot more time in VB.Net, written a lot more code in it,
> and I am beginning to see the point, a little. There are so many different
> types that you could declare - true, many are of the same basic type, ie
> all the different specific types of exception that you can Catch - but it
> makes me wonder about the continued value of the "Prefix Everything" kind
> of naming convention. It may be that it is easier/quicker to pause the
mouse
> over, or look at the declaration of, a var to see what it is exactly.
>
> I guess that personally, I will continue naming basic vars - strings, etc-
> as always (though the numerics will be a headache! int32Loop instead of
intLoop?
> Blech! But I would like to get away from the int/long stuff). Then with
the
> less basic types of object -the exceptions, the collections, etc etc - I
> will be using a convention based on their generic type. For example,
colSomeCollection
> for a collection regardles of whether it is a StringCollection or an
ObjectCollection
> or an XXXCollection and so on...
>
> Any thoughts?
> Cheers,
> Paul
>
>
>
>
>
>
>

[Gregor R. Peisker]

Hi Paul,

<snip/>

> Under the bonnet, however, things are a little different. There was a post
> (by Sam Spencer I believe) a while back, which mentioned in passing that
> MS no longer encouraged the use of the hungarian-style naming convention
> for .Net - apparently because the mouse-over defininition-tooltip thingy
> made it unnecessary.

I'm not convinced by that particular argument. In the same way, there could be traffic
lights all in the same color (instead of red, yellow, green). Or, the lights could be
ordered at random. All that because drivers would have special OptiSense(TM) binoculars
that allow them to discriminate the different signals. When driving towards a traffic
light, they'd just grab them, look, and figure out what's going on. But ultimately, the
light moves faster than the muscles in the right arm. I like IntelliSense, but some things
work better without it.


<snip/>

> Now I have spent a lot more time in VB.Net, written a lot more code in it,
> and I am beginning to see the point, a little. There are so many different
> types that you could declare - true, many are of the same basic type, ie
> all the different specific types of exception that you can Catch - but it
> makes me wonder about the continued value of the "Prefix Everything" kind
> of naming convention. It may be that it is easier/quicker to pause the mouse
> over, or look at the declaration of, a var to see what it is exactly.

As for prefixes based on the type, for the sheer quantity of types that we have now, I
agree. I just think that prefixes can convey other important information besides the type,
such as scope, or the purpose of a variable.

Personally, I've bought into MS's prefixing mania less and less. I try to use one prefix
at the most, and keep them as short as possible. It matters to me to know whether some
variable has class scope, in order to avoid logical errors. Integers get a prefix based on
the purpose. String get as "s", Booleans an "f". But those details don't matter. I use the
same convention in all languages, and it works well, because many concepts are similiar,
and HN can be used very well to express those basic concepts.


<snip/>

> Then with the
> less basic types of object -the exceptions, the collections, etc etc - I
> will be using a convention based on their generic type. For example, colSomeCollection
> for a collection regardles of whether it is a StringCollection or an ObjectCollection
> or an XXXCollection and so on...

Collection class names are funny. In the past, they had a plural name, which should have
been just fine. Now, if you have a collection of RedNosedReindeer objects, it'll be called
RedNosedReindeerCollection, and if it has it's own iterator class the latter will be
called RedNosedReindeerCollectionEnumerator. Talk about verbose! I think this is a case
for a "kind-of-type" or "kind-of-class" prefix.


Regards,
Gregor

[Bob Butler]

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3b131b8d@news.devx.com...
<cut>
> Under the bonnet, however, things are a little different. There was a post
> (by Sam Spencer I believe) a while back, which mentioned in passing that
> MS no longer encouraged the use of the hungarian-style naming convention
> for .Net - apparently because the mouse-over defininition-tooltip thingy
> made it unnecessary.

The only items I've seen from MS are in regard to publicly exposed names,
not to private variables. For that I definitely agree that the prefixes
should not be used. For private variables I'm not convinced yet.

[Patrice Scribe]

If VB.NET is strictly typed (and it is isn't it ?) it should be less
important to use prefixes as type problems would be caugth at compile time.

Also the type could be inferred from the variable name. For example a prefix
is usefull when using :
- lngFile
- strFile
but
- FileHandle
- FileName seems really self-descriptive enought....

Just my 0,02 ?

--

Patrice Scribe


"Bob Butler" <butlerbob@earthlink.net> a écrit dans le message news:
3b139e20@news.devx.com...
> "Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
> news:3b131b8d@news.devx.com...
> <cut>
> > Under the bonnet, however, things are a little different. There was a
post
> > (by Sam Spencer I believe) a while back, which mentioned in passing that
> > MS no longer encouraged the use of the hungarian-style naming convention
> > for .Net - apparently because the mouse-over defininition-tooltip thingy
> > made it unnecessary.
>
> The only items I've seen from MS are in regard to publicly exposed names,
> not to private variables. For that I definitely agree that the prefixes
> should not be used. For private variables I'm not convinced yet.
>
>

[Bob Butler]

"Patrice Scribe" <scribe@chez.com> wrote in message
news:3b13a690$1@news.devx.com...
> If VB.NET is strictly typed (and it is isn't it ?) it should be less
> important to use prefixes as type problems would be caugth at compile
time.

It's not compile time errors so much as being able to read the code that I'm
concerned with. The tooltips are nice but they only help in the VS IDE and
then only one at a time.

> Also the type could be inferred from the variable name. For example a
prefix
> is usefull when using :
> - lngFile
> - strFile
> but
> - FileHandle
> - FileName seems really self-descriptive enought....

I agree, and I'm starting to do that in many cases myself to see how it
goes. The main stumbling block is having a public property procedure
exposing a private variable... it always seems like the logical choice for
both is the same:

Private CustomerName As String
Public Property CustomerName As String
<etc>

To get around that in case-sensitive languages you can use different casing
(which I can't stand since I find it makes the code much more difficult to
work with) but in VB.Net you are stuck with some sort of naming change.
Doing something line "NameOfCustomer" vs "CustomerName" is also likely to
lead to confusion. I suppose I could just use something like "p" for the
private variable but at that point I may as well stick with the type
prefixes.

For those who do use names like "FileHandle" and "CustomerName" now, how do
you handle the public/private difference in VB?

[Kathleen Dollard-Joeris]

Gregor,

Because I am a long-time fan of single letter Hungarian (more gets in the
way, IMO), this is the reason I am ready to abandon Hungarian

> Personally, I've bought into MS's prefixing mania less and less. I try to
use one prefix
> at the most, and keep them as short as possible. It matters to me to know
whether some
> variable has class scope, in order to avoid logical errors. Integers get a
prefix based on
> the purpose. String get as "s", Booleans an "f". But those details don't
matter. I use the
> same convention in all languages, and it works well, because many concepts
are similiar,
> and HN can be used very well to express those basic concepts.

HN only worked when everybody used the same prefixes. When you knew f was
single or double (who cared about the size), etc. After having dealt with a
project that used d for double (not date, what were they thinking!), and yes
s for single, I came to the conclusion that the era for HN is past.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Russell Jones]

The most common way to differentiate the private variables from the public
properties is to use the "member" syntax--preface the private variable with
an "m" or "m_", eg. mCustomerName or m_CustomerName.

"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3b13aa46@news.devx.com...
> "Patrice Scribe" <scribe@chez.com> wrote in message
> news:3b13a690$1@news.devx.com...
> > If VB.NET is strictly typed (and it is isn't it ?) it should be less
> > important to use prefixes as type problems would be caugth at compile
> time.
>
> It's not compile time errors so much as being able to read the code that
I'm
> concerned with. The tooltips are nice but they only help in the VS IDE
and
> then only one at a time.
>
> > Also the type could be inferred from the variable name. For example a
> prefix
> > is usefull when using :
> > - lngFile
> > - strFile
> > but
> > - FileHandle
> > - FileName seems really self-descriptive enought....
>
> I agree, and I'm starting to do that in many cases myself to see how it
> goes. The main stumbling block is having a public property procedure
> exposing a private variable... it always seems like the logical choice
for
> both is the same:
>
> Private CustomerName As String
> Public Property CustomerName As String
> <etc>
>
> To get around that in case-sensitive languages you can use different
casing
> (which I can't stand since I find it makes the code much more difficult to
> work with) but in VB.Net you are stuck with some sort of naming change.
> Doing something line "NameOfCustomer" vs "CustomerName" is also likely to
> lead to confusion. I suppose I could just use something like "p" for the
> private variable but at that point I may as well stick with the type
> prefixes.
>
> For those who do use names like "FileHandle" and "CustomerName" now, how
do
> you handle the public/private difference in VB?
>
>
>

[Bob Butler]

"Russell Jones" <arj1@northstate.net> wrote in message
news:3b13bb61$1@news.devx.com...
> The most common way to differentiate the private variables from the public
> properties is to use the "member" syntax--preface the private variable
with
> an "m" or "m_", eg. mCustomerName or m_CustomerName.

Yes, I've seen both "m" and "p" used for this (underscores are almost as
ugly as camel casing IMO) but that leaves me with:
* module level private variables prefixed with "m"
* public names having no prefix
* local variables having no prefix

and that, to me, is inconsistent since local variables vs public names look
the same while local variables vs module variables look different. I really
dislike that convention which is why I keep falling back to the
single-letter hungarian for all variables with the preceeding "m" for
module-level ones.

[Daniel Pratt]

Hi Bob,

Underscores might be ugly, but they're useful for interminably lazy
folks, like myself :-) I just type 'm_' and then Ctrl + <Spacebar> and
voila!

Regards,
Dan

"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3b13bdd6$1@news.devx.com...
> "Russell Jones" <arj1@northstate.net> wrote in message
> news:3b13bb61$1@news.devx.com...
> > The most common way to differentiate the private variables from the
public
> > properties is to use the "member" syntax--preface the private variable
> with
> > an "m" or "m_", eg. mCustomerName or m_CustomerName.
>
> Yes, I've seen both "m" and "p" used for this (underscores are almost as
> ugly as camel casing IMO) but that leaves me with:
> * module level private variables prefixed with "m"
> * public names having no prefix
> * local variables having no prefix
>
> and that, to me, is inconsistent since local variables vs public names
look
> the same while local variables vs module variables look different. I
really
> dislike that convention which is why I keep falling back to the
> single-letter hungarian for all variables with the preceeding "m" for
> module-level ones.
>
>

[Jim Pragit]

Hi Bob,

"Bob Butler" <butlerbob@earthlink.net> wrote:
>I really
>dislike that convention which is why I keep falling back to the
>single-letter hungarian for all variables with the preceeding "m" for
>module-level ones.

Out of curiousity, when you're using single-letter Hungarian, how do you
differentiate between different data types that start with the same letter
(i.e. b = Byte or Boolean, d = Date or Double, s = String or Single)?

- Jim
Elegance and consistency are *features* I wish VB had.

[Gregor R. Peisker]

Hi Kathleen,

> HN only worked when everybody used the same prefixes. When you knew f was
> single or double (who cared about the size), etc. After having dealt with a
> project that used d for double (not date, what were they thinking!), and yes
> s for single, I came to the conclusion that the era for HN is past.

that's an interesting position.

However, I think it doesn't matter whether everybody uses the same prefixes. This might
seem like missing the whole point of a naming convention, but it depends on what the
prefixes are used for.

I think focusing on types is asking for trouble. Think of integers (and their recent
redefinition), "b" (Boolean or Byte?), and, as you mention, "d" (Date of Double?). Also,
with regard to types, having the same types consistently is crucial (like numbers with the
same precision); but that is determined when you declare a variable or parameter, and at
this point, variable naming doesn't help to remember the right type.

On the other hand, considering the purpose or the scope of a variable, allows for a more
relaxed approach. For example, I've had to work with code where private class members were
prefixed with just an underscore, which is not what I prefer. But what's the problem? The
important thing was to know: "This guy understands that scoping prefixes help avoid
logical errors". And it's not a big deal to memorize two different prefixes; it's the
concept that matters.

Regards,
Gregor

[Jonathan Allen]

> There was a post
> (by Sam Spencer I believe) a while back, which mentioned in passing that
> MS no longer encouraged the use of the hungarian-style naming convention
> for .Net

I don't see how that conclusion can be reached by a VB programmer. MS has
never promoted Hungarian notation for public identifiers in VB; you never
see classed like CPrinter or CFile. They are just codifying that stance with
the CLS. As for internal variable names, they haven't said a word either
way.

--
Jonathan Allen


"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3b131b8d@news.devx.com...
>
> G'day all.
>
> I was just mucking about with visual inheritance last night, and it got me
> thinking about standards and conventions.
>
> The way I see it is that vb.net makes it very easy to maintain what I will
> call "output standards" - ie the basic look/feel & baseline behaviour of
> your typical UI app/components. Visual (and indeed non-visual) inheritance
> is a powerful tool in this regard, IMO.
>
> Under the bonnet, however, things are a little different. There was a post
> (by Sam Spencer I believe) a while back, which mentioned in passing that
> MS no longer encouraged the use of the hungarian-style naming convention
> for .Net - apparently because the mouse-over defininition-tooltip thingy
> made it unnecessary.
>
> Personally, I thought "blow that!" - I do not want to have to pause my
mouse
> over a var, or go to the declaration to see what the var is exactly. I
like
> the hungarian because I know strSomething is (probably) a string, at first
> glance.
>
> Now I have spent a lot more time in VB.Net, written a lot more code in it,
> and I am beginning to see the point, a little. There are so many different
> types that you could declare - true, many are of the same basic type, ie
> all the different specific types of exception that you can Catch - but it
> makes me wonder about the continued value of the "Prefix Everything" kind
> of naming convention. It may be that it is easier/quicker to pause the
mouse
> over, or look at the declaration of, a var to see what it is exactly.
>
> I guess that personally, I will continue naming basic vars - strings, etc-
> as always (though the numerics will be a headache! int32Loop instead of
intLoop?
> Blech! But I would like to get away from the int/long stuff). Then with
the
> less basic types of object -the exceptions, the collections, etc etc - I
> will be using a convention based on their generic type. For example,
colSomeCollection
> for a collection regardles of whether it is a StringCollection or an
ObjectCollection
> or an XXXCollection and so on...
>
> Any thoughts?
> Cheers,
> Paul
>
>
>
>
>
>
>

[Jonathan Allen]

> Out of curiousity, when you're using single-letter Hungarian, how do you
> differentiate between different data types that start with the same letter
> (i.e. b = Byte or Boolean, d = Date or Double, s = String or Single)?

The company I work for uses this...
s String
n Number (any size)
b Boolean
bt Byte (when used to store binary, not numeric, data)
o Object
xo Object that needs to be Disposed locally (.Net Only)
g GUID (a String in VB, a GUID in VB.Net)
sql A string containing SQL

Basically it comes down to use, not type.

--
Jonathan Allen


"Jim Pragit" <NoSpam@NoSpam.com> wrote in message
news:3b13cb06@news.devx.com...
>
> Hi Bob,
>
> "Bob Butler" <butlerbob@earthlink.net> wrote:
> >I really
> >dislike that convention which is why I keep falling back to the
> >single-letter hungarian for all variables with the preceeding "m" for
> >module-level ones.
>
> Out of curiousity, when you're using single-letter Hungarian, how do you
> differentiate between different data types that start with the same letter
> (i.e. b = Byte or Boolean, d = Date or Double, s = String or Single)?
>
> - Jim
> Elegance and consistency are *features* I wish VB had.

[Jonathan Allen]

> and that, to me, is inconsistent since local variables vs public names
look
> the same while local variables vs module variables look different.

I used to program that way, but I was always getting fragged by naming
clashes. Since I was taught the "m_" prefix, I haven't gone back. It is just
too covenant to give up.


--
Jonathan Allen


"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3b13bdd6$1@news.devx.com...
> "Russell Jones" <arj1@northstate.net> wrote in message
> news:3b13bb61$1@news.devx.com...
> > The most common way to differentiate the private variables from the
public
> > properties is to use the "member" syntax--preface the private variable
> with
> > an "m" or "m_", eg. mCustomerName or m_CustomerName.
>
> Yes, I've seen both "m" and "p" used for this (underscores are almost as
> ugly as camel casing IMO) but that leaves me with:
> * module level private variables prefixed with "m"
> * public names having no prefix
> * local variables having no prefix
>
> and that, to me, is inconsistent since local variables vs public names
look
> the same while local variables vs module variables look different. I
really
> dislike that convention which is why I keep falling back to the
> single-letter hungarian for all variables with the preceeding "m" for
> module-level ones.
>
>

[Gregor R. Peisker]

Hi Bob,

> For those who do use names like "FileHandle" and "CustomerName" now, how do
> you handle the public/private difference in VB?

The problem has many facetts. There is the property name, the member name, and possibly a
local variable or parameter name like in this pseudo-code:

Private m_FileHandle As Integer
Public ReadOnlyProperty FileHandle As Integer
Get
FileHandle = m_FileHandle
End Get
End Property
Friend Sub SetFileHandle(ByVal hFile As Integer)
m_FileHandle = hFile
End Sub

As a general rule, the member name gets a prefix, but otherwise it's like the property
name, which doesn't have any prefixes. Local variables or parameter get prefixes where
appropriate, in order to tell them appart from properties (although there's no name
conflict, there might be IDE autocapitalization issues; and it's safer anyway). I avoid
multiple prefixes (aka, "Hungarian ****") in general.

Another problem arises if the property's type is some class or otherwise user-defined
type. If the a property returns a Head, isn't Head the obvious name? How would you
doctor the following:

Private Head As Head
Public ReadOnly Property Head As Head
Get
Head = Head
End Get
End Property
Friend Sub SetHead(ByVal Head As Head)
Head = Head
End Sub

Regards,
Gregor

[Bob Butler]

"Jim Pragit" <NoSpam@NoSpam.com> wrote in message
news:3b13cb06@news.devx.com...
>
> Hi Bob,
>
> "Bob Butler" <butlerbob@earthlink.net> wrote:
> >I really
> >dislike that convention which is why I keep falling back to the
> >single-letter hungarian for all variables with the preceeding "m" for
> >module-level ones.
>
> Out of curiousity, when you're using single-letter Hungarian, how do you
> differentiate between different data types that start with the same letter
> (i.e. b = Byte or Boolean, d = Date or Double, s = String or Single)?

Similar to other responses, I use 2 or 3 characters when needed. For me, b,
d & s would be Boolean, Date and String respectively since I use those far
more often than byte, double or single.

[Bob Butler]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3b13e6ca@news.devx.com...
> > and that, to me, is inconsistent since local variables vs public names
> look
> > the same while local variables vs module variables look different.
>
> I used to program that way, but I was always getting fragged by naming
> clashes. Since I was taught the "m_" prefix, I haven't gone back. It is
just
> too covenant to give up.

So it really is a religious issue with you? <g>

I use the "m", I just can't stand reading code with underscores all over.
Purely personal preference.

[Bob Butler]

"Gregor R. Peisker" <gregor@peisker.de> wrote in message
news:3b13dace@news.devx.com...
<cut>
> Private Head As Head
> Public ReadOnly Property Head As Head
> Get
> Head = Head
> End Get
> End Property
> Friend Sub SetHead(ByVal Head As Head)
> Head = Head
> End Sub

Currently, probably like this:
Private moHead As Head
Public ReadOnly Property Head As Head
Get
Head = moHead
End Get
End Property
Friend WriteOnly Property SetHead As Head
Set
moHead = Value
End Set
End Sub

[Jonathan Allen]

> I use the "m", I just can't stand reading code with underscores all over.

I like the underscore because it provides a natural separate between the two
prefixes. Lets say I have a class called MissionStatus.

msMain 'member string Main
msMain 'local MissisonStatus Main
OR
m_sMain 'member string Main
msMain 'local MissisonStatus Main

I know the example is a bit contrived, but the situation could arise.
Especially if you have a large set of scope and use prefixes.

--
Jonathan Allen


"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3b13ea77$1@news.devx.com...
> "Jonathan Allen" <greywolf@cts.com> wrote in message
> news:3b13e6ca@news.devx.com...
> > > and that, to me, is inconsistent since local variables vs public names
> > look
> > > the same while local variables vs module variables look different.
> >
> > I used to program that way, but I was always getting fragged by naming
> > clashes. Since I was taught the "m_" prefix, I haven't gone back. It is
> just
> > too covenant to give up.
>
> So it really is a religious issue with you? <g>
>
> I use the "m", I just can't stand reading code with underscores all over.
> Purely personal preference.
>
>
>

[Bob Butler]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3b13f154@news.devx.com...
> > I use the "m", I just can't stand reading code with underscores all
over.
>
> I like the underscore because it provides a natural separate between the
two
> prefixes.

I understand, but to me the "_" is an interruption when reading the code.
For some reason it always slows me for a fraction of a second while I
process it and has a very jarring effect. Omitting the underscore just
works better for me.

[Phil Weber]

> How do you differentiate between different data types
> that start with the same letter (i.e. b = Byte or Boolean,
> d = Date or Double, s = String or Single)?

Jim: In VB6, I use (in roughly descending order of frequency):

s = String
b = Boolean
t = Byte
dat = Date
r = Single (Real)
dbl = Double

In VB.NET, I haven't been using type prefixes.
---
Phil Weber

[Kathleen Dollard-Joeris]

Gregor,

At this point I am still leaning to prefixing variables with scope, so it
sounds like we agree <g>

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Kathleen Dollard-Joeris]

Jonathan,

> > and that, to me, is inconsistent since local variables vs public names
> look
> > the same while local variables vs module variables look different.

You missed the question, and I think it is a valid one. I don't have an
answer although I have experimented with retaining HN for local variables
and casing.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Bob Butler]

"Kathleen Dollard-Joeris" <joeris@nomailplease.org> wrote in message
news:3b150ba9@news.devx.com...
> Jonathan,
>
> > > and that, to me, is inconsistent since local variables vs public names
> > look
> > > the same while local variables vs module variables look different.
>
> You missed the question, and I think it is a valid one. I don't have an
> answer although I have experimented with retaining HN for local variables
> and casing.

That was me you quoted, not Jonathan, but I don't understand what question
you think I missed.

[Jonathan Allen]

Huh?

--
Jonathan Allen


"Kathleen Dollard-Joeris" <joeris@nomailplease.org> wrote in message
news:3b150ba9@news.devx.com...
> Jonathan,
>
> > > and that, to me, is inconsistent since local variables vs public names
> > look
> > > the same while local variables vs module variables look different.
>
> You missed the question, and I think it is a valid one. I don't have an
> answer although I have experimented with retaining HN for local variables
> and casing.
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --
>
>

[Kathleen Dollard]

Bob,

Sorry for the confusion. Jonathan missed your question, I thought.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Richard Curzon]

Most magazine authors and small component writers pride themselves in not
using conventions. It's part of being a free spirit, I think. <g>.

But can anyone can show us a robust 100,000 line multiperson project,
without naming conventions and nary a type error over the project? I doubt
it, haven't seen it happen. Does dot-net change anything? Not likely.

MS PSS does specify three character type prefixes that they recommend, for
previous VBs. And as people say, there's nothing to indicate they believe
dot-net changes the need for prefixes.

OTOH I frequently see bad assumptions about type that could have been
avoided by good naming, even in small projects.

The VS7 IDE will give you type info if you "ask", but nobody "asks" every
time they write a line of code. So far in limited experience of VS7, people
seem to find that type info balloon annoying and turn it off. In fact, I
think it's off by default, isn't it?

The compiler can't catch runtime errors like overflows, or failures of
typecasts, or QueryInterface failures when you pass around COM-based
references, etc, or many others.

Other reasons:

1. If you are writing a serious system, I hope you do some peer code
reviews. Usually done sitting in a room with paper or overheads, or on a
commuter train with printouts, and no IDE hints!

2. And with dot-net genericity, VB joins the rest of the world. There's
more chance people might be using the free command line compiler with a
multi-language code editor, not an IDE.

When I'm dictator, I use 1 char scope, 3 char type convention, no scope
character for locals. If not, I adapt to local standards.

---

The DOTNET Problem: The number of types added to each generation of VB was a
trickle, then a stream. With VB.net we are truly "drinking from the
firehose".

I don't bother inventing a 3 char type name for every "brand new" type in
CLR, just the ones used often in a project, say half a dozen. For others, I
just use "obj" and a slightly longer name. Long names are easy if you let
[Ctrl-Space] do the keyboarding for you.

For component interfaces used by other programmers, I don't use prefix, but
try to make the type as obvious as possible in the name.

....my 2 cents, Canadian <g>
Richard Curzon
Toronto

--
-----
Live without dead time - Raoul Vaneigem
May I borrow your towel, my car just hit a water buffalo - Chevy Chase