Dim Form as Form OK usage???

[Just Me]

I've tried in a few places using a variable name Form and it appears to be
OK.
For example:
Public Shared Sub WritePositionsInRegistry(ByVal Form As Form, ByVal
SubkeyName As String)

Is it OK to use a Type name as a variable name. For example,:

Set(ByVal Color As Color)

Sometimes I can't think of a fitting argument name other then the Type name.



Thanks

 

[Chris, Master of All Things Insignificant]

It would be considered very bad form to write a program this way. Since a
lot of Type names have shared function that can called directly, it makes
your program hard to read. Espcially when you can fix the problem with a
simple prefix.

Public Shared Sub WritePositionsInRegistry(ByVal frmForm As Form, ByVal
SubkeyName As String)

Just my two cents
Chris

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,
There are a group of developers, such as Chris, who feel that using the type
name for the variable is a bad thing. There are another group of developers,
usually OO developers, who feel using the type name for the variable name
may be a good idea.

I tend to fall into this second group, as that is the way I interpret the
"Parameter Naming Guidelines"
http://msdn.microsoft.com/library/d...enref/html/cpconParameterNamingGuidelines.asp
from the ".NET Design Guidelines for Class Library Developers".

Naming the parameter for the type may be the best fit because its:
- a descriptive name - 'form' may be the most descriptive name for variable
given how its used. parentForm or childForm may be better names.
- describe a parameter's meaning - IMHO its obvious 'form' means form.
- Do not prefix parameter names with Hungarian type notation (IMHO frmForm
is "duplication", a number of OO developers try to avoid duplication, its
avoid duplication is a major tenent of Refactoring
http://www.refactoring.com)

Also the above guidelines suggest not to abbreviate names, 'form' is better
then 'frm'. Is frm short for Form, Farm, or Functional Resources Manager?

http://msdn.microsoft.com/library/d...ry/en-us/cpgenref/html/cpconAbbreviations.asp

In other words, rather then frmForm as Chris suggests I would consider
formParent, or parentForm. Depending on what I am doing would decide if I
use the type as a prefix or suffix... Sometimes I simply use parent or child
if its "obvious" in the context what the variable represents, remember the
type of the variable also contributes to the meaning of the variable...

There is another group of developers, mostly Java, that prefer to prefix the
name with "the", "a" or "an" ("a" as in singular not a Hungarian array
prefix), which makes the code "easier" to read as English.

Public Shared Sub WritePositionsInRegistry(ByVal theForm As Form)
For Each aChild As Control in theForm.Controls
aChild.BackColor = theForm.BackColor
Next
End Sub

You find "the", "a", and "an" a lot in Martin Fowler's Refactoring book, as
all the samples are in Java.

If my shop had a perceived need for prefixes (Hungarian hold overs) I would
promote the third method, for its perceived readability...

Hope this helps
Jay

 

[Chris, Master of All Things Insignificant]

I agree that frmForm is redunant. frmMain is how I have always done it, but
this is from someone that has not had to work in a company with large teams
and had to standardize naming conventions. Very nice write-up on this idea
Jay.

Chris

 

[Larry Serflaten]

Is it OK to use a Type name as a variable name. For example,:

Since it works, that must mean MS has decided it is OK. You
also have the option of rebooting the user's computer when your
application ends. That also is allowed.

But there is a difference between what is allowed, and what makes
for common/practical sense. In one case, its a hassle for the user,
and in the other, a hassle for the next guy who looks at your code.

Set(ByVal Color As Color)

Sometimes I can't think of a fitting argument name other then the Type name.

Set ??? Set what? Typically, generic names fit well in those situations:

ForeColor(ByVal Value As Color)

LFS

 

[Herfried K. Wagner [MVP]]

Larry,

Since it works, that must mean MS has decided it is OK. You
also have the option of rebooting the user's computer when your
application ends. That also is allowed.

But there is a difference between what is allowed, and what makes
for common/practical sense. In one case, its a hassle for the user,
and in the other, a hassle for the next guy who looks at your code.

JFMI: How would you name the first parameter of the method
'SetComboBoxPasswordChar' in this snippet?

Enabling a password char for a combobox control
<URL:http://dotnet.mvps.org/dotnet/faqs/?id=comboboxpasswordchar&lang=en>

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,
What is JFMI?

I would name it "comboBox" (lower case c instead of Upper case C) as I don't
see any other name that is more descriptive or meaning full given the
context...

Jay

 

[Larry Serflaten]

JFMI: How would you name the first parameter of the method
'SetComboBoxPasswordChar' in this snippet?

Enabling a password char for a combobox control
<URL:http://dotnet.mvps.org/dotnet/faqs/?id=comboboxpasswordchar&lang=en>

Since this routine operates on any combobox, the parameter has to target which
combo box is desired, hense: Target

But for that second parameter, its the character that is needed, is it not?
Shouldn't that parameter's name simply be Character?

LFS

 

[Larry Serflaten]

There are a group of developers, such as Chris, who feel that using the type
name for the variable is a bad thing. There are another group of developers,
usually OO developers, who feel using the type name for the variable name
may be a good idea.

I tend to fall into this second group, as that is the way I interpret the
"Parameter Naming Guidelines"

Naming the parameter for the type may be the best fit because its:
- a descriptive name - 'form' may be the most descriptive name for variable
given how its used. parentForm or childForm may be better names.
- describe a parameter's meaning - IMHO its obvious 'form' means form.
- Do not prefix parameter names with Hungarian type notation (IMHO frmForm
is "duplication", a number of OO developers try to avoid duplication, its
avoid duplication is a major tenent of Refactoring
http://www.refactoring.com)

Did you miss this from the naming guidelines:

-Use names that describe a parameter's meaning rather than names that describe a parameter's type.

Public Shared Sub WritePositionsInRegistry(ByVal theForm As Form)
For Each aChild As Control in theForm.Controls
aChild.BackColor = theForm.BackColor
Next
End Sub

Here, the form is the source object for the controls that will be saved, so, IMHO,
the parameter name could be "Source"

Public Shared Sub WritePositionsInRegistry(ByVal Source As Form)

Also, I do not favor camel case for parameter names. I do favor camel case
for local variables, and the parameter might be considered a local variable, but
for all practical purposes, it is sent from the outside world, and shows up in
intellisence formated as supplied. I prefer seeing proper case in parameters,
case in point:

Dim x As String = Chr(65)

The parameter for Chr is "CharCode" not "charCode", similarly for Asc.
(However other parts do show camel cased parameters....)

LFS

 

[Herfried K. Wagner [MVP]]

Jay,

What is JFMI?

"Just for my information" ;-))).

I would name it "comboBox" (lower case c instead of Upper case C) as I
don't see any other name that is more descriptive or meaning full given
the context...

That's what I thought too, but I didn't use the lower case "c" because I
don't like the camel case naming convention ;-))).

 

[Herfried K. Wagner [MVP]]

Larry,

Since this routine operates on any combobox, the parameter has to target
which
combo box is desired, hense: Target

But for that second parameter, its the character that is needed, is it
not?
Shouldn't that parameter's name simply be Character?

Both are interesting points I should consider !

 

[Jay B. Harlow [MVP - Outlook]]

Larry,

Did you miss this from the naming guidelines:

-Use names that describe a parameter's meaning rather than names that
describe a parameter's type.

Yep sure did, Oh! wait, it was the second point I made!

Also, I do not favor camel case for parameter names. I do favor camel
case

I hope you will understand that "splitting hairs" is not my game, have a
nice day.

camelCase or ProperCase parameters is immaterial to the question! Hence
there is no reason to discuss it.

Hope this helps
Jay

 

[Larry Serflaten]

I tend to fall into this second group, as that is the way I interpret the
"Parameter Naming Guidelines"

- describe a parameter's meaning - IMHO its obvious 'form' means form.

(From: -Use names that describe a parameter's meaning rather than names that
describe a parameter's type.)

Interesting interpretation. What does form mean, exactly? If you say it means
that a form is supposed to be passed in, you are describing the parameter's type.

So I have to ask, what does 'form As Form' tell you about the parameter, other
than it is supposed to be of the type Form?

LFS

 

[Cor Ligthert]

Just Me,

For me it is very simple, anything that can give misunderstandings too
another than myself is bad to use.

Wheter it does give a program error or not is not important in that.

When there is extra time needed to understand a program, while that could
have been avoided with good names, than in my opinion the programmer who did
that is a bad programmer.

Using "dim form as form" comes in my opinion in that category, some playing
of the programmer to statify himself (the Dutch word express it better
because that has two meanings).

Just my thought,

Cor

 

[Just Me]

Since it works, that must mean MS has decided it is OK. You
also have the option of rebooting the user's computer when your
application ends. That also is allowed.

But there is a difference between what is allowed, and what makes
for common/practical sense. In one case, its a hassle for the user,
and in the other, a hassle for the next guy who looks at your code.

A property

 

[Just Me]

Thanks for the answers that were directed to help me.

I too don't like the camel naming convention but I believe all MS methods
use it so I may just to be consistent (so IntelliSense of mine and MS's look
the same).

Also
Bevel color as Color
and
something = color

Seems to me a clear as
Bevel the as Color
and
something = the

Also I've been using Main and Cancel instead of formalin and btnCancel and
grew to like it better this way.

But I can tell from the replies everyone does not agree which are the best
methods.

My problem was more basic then the answers implied - I was just wondering if
it was OK in the sense: does it work OK!

Thanks

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,

My problem was more basic then the answers implied - I was just wondering
if it was OK in the sense: does it work OK!

Yes the compiler allows you to name variables, parameters, fields, &
properties for types.

I have yet to see an actual negative side effect to using the same name. The
closest negative side effect is the Shared member "problem" that was
mentioned, however the compiler is smart enough to create valid IL, so there
is no actual "problem"...

An annoyance of using the type as the variable name, is the Intellisense
gets confused, however this does not impact the IL created...

Also I've been using Main and Cancel instead of formalin and btnCancel and
grew to like it better this way.

I normally suffix my forms with Form or Dialog depending on if its a "Form"
or a "Dialog". For example MainForm & OptionsDialog.

I use Form.Show to show forms, while I use Form.Dialog to use dialogs.

For buttons I have been spelling out the type as in "buttonCancel", however
I see a certain appeal in simply calling it "Cancel". I have a Timer in a
Service that I have simply named "ScanWait", the code actually reads rather
nicely.

ScanWait.Start

Sub ScanWait_Elapsed

Dim wait As TimeSpan = ...
ScanWait.Interval = wait.TotalMilliseconds

Hope this helps
Jay

Thanks for the answers that were directed to help me.

I too don't like the camel naming convention but I believe all MS methods
use it so I may just to be consistent (so IntelliSense of mine and MS's
look the same).

Also
Bevel color as Color
and
something = color

Seems to me a clear as
Bevel the as Color
and
something = the

Also I've been using Main and Cancel instead of formalin and btnCancel and
grew to like it better this way.

But I can tell from the replies everyone does not agree which are the best
methods.

My problem was more basic then the answers implied - I was just wondering
if it was OK in the sense: does it work OK!

Thanks

<<snip>>

 

[Herfried K. Wagner [MVP]]

Jay,

I use Form.Show to show forms, while I use Form.Dialog to use dialogs.

I assume you use 'Form.ShowDialog' for showing dialogs .

 

[Just Me]

An annoyance of using the type as the variable name, is the Intellisense
gets confused

I haven't seen signs of confusion.
I'm now looking at an Intellisense:

WritePositionsInRegistry(form As SystemsWindowsForms.Form, subKeyName as
String)

Looks good to me!

What do you think?


PS
I said
"I too don't like the camel naming convention "
but I mean aesthetically
I do like the fact that variables look different then Classes, Properties
and Functions for which I use Pascal naming.

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,

Doh!!

Yes I use Form.ShowDialog for showing dialogs...

Thanks for the assist...

Jay