variables with the same name best practice 4

[sub5]

If I have a variable set as Private strName as String in the declarations section of form1 and I have another Private strName as String declaration in form2 will that cause any problems?

I want the same name because they represent the same piece of data type, but I want the instance ie Jack or John to only be read and available within each form.

What happens if I have another variable declared in a stand alone module as Public strName as String.

Is there a best practice? ie keep the two private declarations (so when maintaining the programmer knows that this variable is only relevant to this form) or combine them as a Public StrName as String variable in a stand alone module (form1 and form2 are never open at the same time) so the whole project is less messy ie without duplication of the same variable type?

Thanks in advance for your information and thoughts.

 

[Remou]

You may find this:

http://www.xoc.net/standards/rvbanc.asp

useful.
The two private strings will not cause a problem, but using naming conventions should make like easier, that way, the public string would become, say, gstrName.

 

[sub5]

Thanks Remou,
do you have any thoughts on what would be best practice / makes for easier maintenance re a single global variable or two private form based variables?
I think I'd go for the two privates...

 

[Remou]

You would be right, according to this:

Variables should always be declared with the smallest level of scope and the shortest lifetime possible. Thus, you should declare variables with Dim inside of procedures by preference. If you need a longer lifetime, then use Static. If you need a wider scope, use Private. Only use Public as a last resort. Public variables declared in standard modules are global and can be changed by any piece of code throughout the entire project. This makes debugging changes to their value very difficult. Global variables of this sort should only be used in the context where they are set during initialization of the program, then remain static for the rest of the time the program executing.

From: RVBA Coding Conventions,

http://www.xoc.net/standards/rvbanc.asp

 

[MajP]

Remou's quote sums it up pretty good, but this is also a great resource:

http://msdn.microsoft.com/archive/d...us/office97/html/scopelifetimeofvariables.asp

This will give you the big picture, and specifically addresses your question about variables with the same name. Think of your variables as top secret documents. You want to provide access only to those who absolutely need it, you want to have it available out of the safe for the shortest time possible, and you want to destroy it as soon as your done with it.

 

[sub5]

Remou and MajP, I have been using this site for a while now and you guys have always given me great feedback, so thankyou for putting so much into the site. Good job, cheers!

 

[ddiamond]

Just to give a pratical example, I was assigned to take over the maintenance of a fairly buggy access application. Despite my best efforts, the bugs persisted until I systematically replaced almost all of the global variables with private variables. After doing that, the bugs mysteriously vanished, and the app has been stable ever since.

 

[JoeAtWork]

I usually use prefixes to distinguish variables with different scopes.

Global:

Public gstrName as String

Module/Form Level:

Private mstrName as String

Subroutine/Function Level:

Dim strName as String

This not only prevents ambiguity as to which variable is actually to be used, it makes it easier to follow the code. At a glance I know what scope any variable has.

 

[sub5]

Hi Joe, just for clarity

If I have Public strName as string in a stand alone module I can understand calling that Public gstrName as string.

What do you call strName which is in a form but is Public not private? Still mstrName or gstrName?

I have public ones because one form passes / calls the value to / from another.

 

[smedvid]

Good thread...

Just curious if there are comments on Public Functions versus Private? Are there memory concerns? Do Puiblic Functions take up memory?

tia,


Steve Medvid
"IT Consultant & Web Master"

http://www.saveourfarm.com

Chester County, PA Residents
Please Show Your Support...

 

[JoeAtWork]

sub5 - I would still give it a name according to it's visibility to other modules. So if it's global, I would call it gstrName no matter where it is declared.

That being said, I don't think I ever declare global variables in forms, on the logic that if it's used by more than one form, it doesn't belong to any one particular form. When I need to pass information between forms, I tend to use a more generic variable name like gstrDialogReturnValue.

smedvid - I really don't know if there are memory concerns for public vs. private functions. I tend to make scope deceisions entirely based on the principle of giving least possible access.

 

[PHV]

I don't think I ever declare global variables in forms
why not ?
Global form's variables are just new properties of this form.
Global form's functions are just new methods

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[JoeAtWork]

PHV - if I want to give the form a public property I would declare it as a property, but have an internal variable to hold the actual value. Making a public variable lets any code, anywhere change the value, bypassing all validation and business rules. That's not good object-oriented design, in my opinion. An example of what I'm advocating:

Private mstrName As String

Public Property Get Name() As String
   Name = mstrName
End Property

Public Property Let Name(NewName As String)

   'Don't let the name be bigger than the size of 
   'the field in the database
   If Len(NewName) > 50 Then
      Err.Raise 1030 + vbObjectError, "Customer.Name", "The NewName parameter is too big."

   Else
      mstrName = NewName
   End If

End Property