Naming conventions in For... each

[Robert Jacobson]

Hello all,

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)


#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.


#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.


I tend to use the first variation, but wonder if this makes my code less
readable. Does anyone have a preference for any of these, or any other
variations? I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

 

[Fergus Cooney]

Hi Robert,

Shame about number 1. ;-)

I would say the only 'best practice' is don't give your variables the same
name as the class.

Is this a Foo which I see before me,
The handle toward my hand?
Come, let me clutch thee.
I have thee not, and yet I see thee still.

For you are the class not the object,
Or is it the other way round?
And now I'm all confused.


Everything else. I would say, is optional and as varied as you suggest,
and more.

For short pieces of code like a loop, the single letter can be good. I use
'c' for char loops, 'S' for simple string manipulation, 'F' for a Form in a
small Form utility routine, etc. Generally the scope will be small and the
variable used a lot.

For objects in general I use oDis and oDat. (is dat 'cos Oi'm Oirish,
maybe not). It's a habit with history and it's a pretty strong one - but I'm
re-evaluatiing it in .NET. It does have the advantage of using the same name
as the class.

I absolutely <hate> My anything - now <that's> cutesy.

But occasionally I use TheWidget or ThisWidget.

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)

I think that's a really bad convention.

#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.

Seems "nice" to me.

#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.

The "quick" solution.

 

[Robert Jacobson]

LOL! You need to write a book on the Art and Poetry of VB. Now if only you
could come up with bawdy VB limericks. "There was a VB programmer from
Nantucket..."


[Snip]

 

[Robert Jacobson]

Well, two votes against my typical practice. I'll see if I can live with
aFoo, or the C# variation. Habits are hard to break. <g>

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)

I think that's a really bad convention.

#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.

Seems "nice" to me.

#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.

The "quick" solution.

 

[Rick Mogstad]

Hello all,

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)

Yeah, not my favorite approach. Aids in confusion later.

#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.

This is my choice.

#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.

This works too, however, if we keep copying what they do in C#, it will only give them more reason
to think they are better than us...

 

[Jay B. Harlow [MVP - Outlook]]

Fergus,

I would say the only 'best practice' is don't give your variables the same
name as the class.

Curious on where you came up with this idea? ;-)

As it seems to me to be the best practice! As the names should be
descriptive enough that the name & type can be used to determine its
meaning. If the type happens to be the most descriptive name then why not
use it?

In other words if I have a Person object, why not name the field person,
especially when I am dealing with a generic person or I am iterating a
collection of specialized (derived objects) people objects?

I don't have a single web link handy...

Just a thought
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Robert,

Does anyone have a preference for any of these, or any other
variations?

I use a variation of #1:

For Each foo As Foo in Foos
...
Next

Notice the lower case f in foo, I follow the .NET Design Guidelines for
Class Library Developers and all variables, fields & parameters are
camelCased.

Unless I have a more descriptive name I use the type name, as names should
be descriptive enough that the name & its type can be used to determine its
meaning. If the type happens to be most descriptive then that is the name I
use. On rare occasions will I use an abbreviations of the type, usually when
the type name is a reserved word, for example ch for Char, str for String.

Right now I don't have a specific link.

I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

I don't think there is a best practice per se. I tend to feel as long as you
are consistent within your project, solution, team, enterprise. Remember the
variable you use is more then likely private to the method, so it really
doesn't matter, its there more for your & your teams readability.

Hope this helps
Jay

Hello all,

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)


#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.


#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.


I tend to use the first variation, but wonder if this makes my code less
readable. Does anyone have a preference for any of these, or any other
variations? I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

 

[Herfried K. Wagner [MVP]]

#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.

This is my choice.

#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.

This works too, however, if we keep copying what they do in C#, it will only give them more reason
to think they are better than us...

I often used something like 'f' for loop variables very long time before
C# has been invented.

 

[Herfried K. Wagner [MVP]]

In other words if I have a Person object, why not name the field person,
especially when I am dealing with a generic person or I am iterating a
collection of specialized (derived objects) people objects?

It's harder to distinct between the call of a class method or an
instance method for the programmer who reads the code.

 

[Herfried K. Wagner [MVP]]

LOL! You need to write a book on the Art and Poetry of VB. Now if only you
could come up with bawdy VB limericks. "There was a VB programmer from
Nantucket..."

ROFL

 

[Cor]

Hi Robert,

When I see this, it reminds me on the first time I started with a database.

For each mare as horse in the stable
'bring it some water
next

I think that your program has to describe what you are doing that is the
first rule in all programming.

Cor

 

[Robert Jacobson]

Good points, Jay. I tend to prefer Pascal casing for variables. (I had
thought that was the MS recommendation for VB.Net.... perhaps I'm wrong.)
However, your suggestion sounds like a nice compromise for distinguishing
between the instance foo and the class Foo.

All of this makes me nostalgic for the bad-old-days of Hungarian naming
conventions from Hell. <g>

Robert,

Does anyone have a preference for any of these, or any other
variations?

I use a variation of #1:

For Each foo As Foo in Foos
...
Next

Notice the lower case f in foo, I follow the .NET Design Guidelines for
Class Library Developers and all variables, fields & parameters are
camelCased.

Unless I have a more descriptive name I use the type name, as names should
be descriptive enough that the name & its type can be used to determine its
meaning. If the type happens to be most descriptive then that is the name I
use. On rare occasions will I use an abbreviations of the type, usually when
the type name is a reserved word, for example ch for Char, str for String.

Right now I don't have a specific link.

I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

I don't think there is a best practice per se. I tend to feel as long as you
are consistent within your project, solution, team, enterprise. Remember the
variable you use is more then likely private to the method, so it really
doesn't matter, its there more for your & your teams readability.

Hope this helps
Jay

Hello all,

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the same name
for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)


#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.


#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.


I tend to use the first variation, but wonder if this makes my code less
readable. Does anyone have a preference for any of these, or any other
variations? I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

 

[Rick Mogstad]

#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.

This is my choice.

#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and to the
point.

This works too, however, if we keep copying what they do in C#, it will only give them more reason
to think they are better than us...

I often used something like 'f' for loop variables very long time before
C# has been invented.

ROFL. This was more of a joking statement than anything. There is almost no difference between
this and Example2 as far as Im concerned.

 

[Herfried K. Wagner [MVP]]

ROFL. This was more of a joking statement than anything. There is almost no difference between
this and Example2 as far as Im concerned.

;-)

 

[Fergus Cooney]

Hi Jay,

|| > I would say the only 'best practice' is don't give your
|| > variables the same name as the class.
||
|| Curious on where you came up with this idea? ;-)
|| As it seems to me to be the best practice!

The 'I would' and the quotes around 'best practice' - it's all my own. ;-)

I don't like the idea of using the same name at all. I think there's a
case in C# for using the same name with a lowercase, but that's because it's
<not> the same name.

In VB I think it's folly. There's nothing but vigilance to prevent the
capitalisation being incorrect. Oops all of a sudden, which one is it supposed
to be? And either way, foo and Foo are the same to VB. What do you do when you
want a Shared member of Foo? What does Junior understand when s/he's reading
your code?

But perhaps you mean it's best practice in the same sort of context that I
use my 'c', 'S' and 'F' - small-scope, self-contained, many references? I'd
hate to read code in which a class name was a variable name throughout the
code, camel cased or not. [That camel casing makes me shudder is perhaps a
small factor there, lol].

With an oFoo As Foo here, and a MyBar As Bar there....
Here a TheFoo, there an aBar...
Everywhere a camel As Camel.

;-)

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

Notice the lower case f in foo, I follow the .NET Design Guidelines for
Class Library Developers and all variables, fields & parameters are
camelCased.

IMO a really ugly convention. I will never use it.

SCNR

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,
Yes that is the one downside!

However! if the compiler did not allow calling class members on variables,
then you could tell as the variable is camelCased while the class is
ProperCased.

Unfortunately VS.NET 'fixes' the names for you so they are all cased for the
variable...

Of course the above may have no bearing on reality.

That's my story and I'm sticking too it ;-)

Jay

 

[Herfried K. Wagner [MVP]]

Good points, Jay. I tend to prefer Pascal casing for variables. (I had
thought that was the MS recommendation for VB.Net.... perhaps I'm wrong.)

The VB.NET Runtime Library uses this convention and I like it much more
than the butt-ugly camel case convention. The names of parameters and
variables IMO do not matter at all, there should not be any problems
when using the Pascal case convention.

All of this makes me nostalgic for the bad-old-days of Hungarian naming
conventions from Hell. <g>

I still like the Hungharian convention. It seems that the developers of
..NET looked at Java's bad naming conventions too much.

 

[Jay B. Harlow [MVP - Outlook]]

Robert,
As I said I follow the .NET Design Guidelines, however they do not
specifically mention local variables (at least I am not seeing it right
now), I follow parameter & field conventions for local variables also.

Note for fields I prefix with m_, as VB.NET does not allow a camelCased
field to match a PascalCased Property.

Note when I said ProperCased I was using it as synonymous with PascalCased.

I know I've read way to many 'recommendations' to keep track of where I
found what where. So generally its what is in the Design Guidelines with a
handful of exceptions...

Hope this helps
Jay

Good points, Jay. I tend to prefer Pascal casing for variables. (I had
thought that was the MS recommendation for VB.Net.... perhaps I'm wrong.)
However, your suggestion sounds like a nice compromise for distinguishing
between the instance foo and the class Foo.

All of this makes me nostalgic for the bad-old-days of Hungarian naming
conventions from Hell. <g>

I use a variation of #1:


Notice the lower case f in foo, I follow the .NET Design Guidelines for
Class Library Developers and all variables, fields & parameters are
camelCased.

Unless I have a more descriptive name I use the type name, as names should
be descriptive enough that the name & its type can be used to determine its
meaning. If the type happens to be most descriptive then that is the

name

I
use. On rare occasions will I use an abbreviations of the type, usually when
the type name is a reserved word, for example ch for Char, str for String.

Right now I don't have a specific link.

I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."

I don't think there is a best practice per se. I tend to feel as long as you
are consistent within your project, solution, team, enterprise. Remember the
variable you use is more then likely private to the method, so it really
doesn't matter, its there more for your & your teams readability.

Hope this helps
Jay

Hello all,

If I have a class called "Foo," is there a preferred naming convention for
iterating through each Foo instance in a collection of Foos? I've seen
several different variations, even in the MSDN documentation:


#1:
For each Foo as Foo in Foos
...
Next Foo

This variation is direct, but a bit ambiguous since it's using the

same
name

for the Foo class and the Foo instance. (I know that the "Foo" in "Next
Foo" is optional -- I'm just including it for clarity.)


#2:
For each MyFoo [or aFoo, TheFoo, etc.] as Foo in Foos
...
Next MyFoo

This variation eliminates the ambiguity by adding a prefix to the instance
name. However, it seems a bit too "cutesy" for me.


#3:
For each f as Foo
...
Next f

This appears to be the C# convention, for better or worse. Terse and

to
the

point.


I tend to use the first variation, but wonder if this makes my code less
readable. Does anyone have a preference for any of these, or any other
variations? I don't want to start a religious war, but am curious about
whether there's a consistent "best practice."