What prefix do you use?

  • Thread starter Thread starter Niklas Östergren
  • Start date Start date
N

Niklas Östergren

Hi!

What prefix do you use for a declared variable which have a scoope of the
module?

If I have a global variable I use <g> as a prefix, like this:

Public gintMyVariableName As Integer

Is it to difficult to understand if I use <m> for a module variable, like
this?

Dim mintMyVariableName As Integer

TIA!
// Niklas
 
Niklas Östergren said:
Hi!

What prefix do you use for a declared variable which have a scoope of the
module?

If I have a global variable I use <g> as a prefix, like this:

Public gintMyVariableName As Integer

Is it to difficult to understand if I use <m> for a module variable, like
this?

Dim mintMyVariableName As Integer
Click to expand...

Personally, I don't use prefixes at all. Seem pretty pointless to me.
 
Niklas said:
Hi!

What prefix do you use for a declared variable which have
a scoope of
the module?

If I have a global variable I use <g> as a prefix, like
this:

Public gintMyVariableName As Integer

Is it to difficult to understand if I use <m> for a module
variable,
like this?

Dim mintMyVariableName As Integer

TIA!
// Niklas
Click to expand...

Nik,

I don't bother to differentiate between variable names in
modules, class modules or form class modules. It seems like
a good idea to begin with but usually proves more trouble
than it's worth.

DO keep identifying global variables seperately the way you
are, that makes life a lot easier.

IIRC there is a write up in the ADH when they refer to the
LR naming conventions.

http://www.developershandbook.com


--
Nick Coe (UK)
AccHelp v1.01 Access Application Help File Builder
http://www.alphacos.co.uk/
Download Free Copy
----
 
Hi NIklas,

The important thing is that your code be comprehensible to the next
developer who has to make it do something new and different. That future
developer will likely be you. There are a couple of widely accepted naming
conventions in the VB(A) and Access worlds. In older and simpler times
there was only one. I follow the Reddick Naming Convention which is widely
available, may even be on www.mvps.org/access via link. It seems to always
be included as an appendix in the Access [YourVersion] Developer's Handbook
by Litwin, Getz, et al. There are several levels of rigor/compliance you
can choose to observe. What ever that level is, you and your team should
all buy into it at the same level.

Equally as important as the naming convention is the narration of what the
code is doing, why it exists. I use a shareware Code Stuffer that surrounds
my procedures with a template for Date, Author, Purpose, etc. and also
includes appropriately labeled Error Handling and reporting code.

HTH
 
Module-level variables are a rich source of frustration,
and should probably be avoided.

Most module-level variables can be replaced with local
variables, or with STATIC local variables. Use the key
word STATIC instead of DIM.

Static and local variables are typically slower, but
the effect is normally trivial. For database connections,
if you need module-level variables, you probably should be
using global variables. And only using Global and Local
variables is easier to keep track of.

Object or Form level variables should be exposed as
properties or controls (for test and debug), and should
be named according to your property/control conventions.
Again, Object or Form level properties/controls that
should not be exposed, should probably be replaced with
static local variables.

(david)
 
David, I agree with most of what you write in these groups, so perhaps I'm
missing something here? I do use module-level variables in most Access
applications I write.

Usually it is when working with the built-in event procedures that I need
the scope and lifetime of a module-level variable. For example, say I need
to know if it was a new record in Form_AfterUpdate. By that stage, the
form's NewRecord property is No (i.e. it's now saved, and not a new
uncommitted record). So:

Dim mbWasNewRecord As Boolean

Private Sub Form_BeforeUpdate(Cancel As Integer)
mbWasNewRecord = Me.NewRecord
End Sub

Private Sub Form_AfterUpdate(Cancel As Integer)
If mbWasNewRecord Then
'do this
Else
'do that
End if
End Sub

When I'm writing my own functions, I tend to pass the arguments rather than
define module-level ones, but we don't have that choice when working with
the built-in event procedures.
 
Well, yes... :~)

I was trying to keep it simple. In particular, I want
to discourage people from using module level recordset
and database variables, which are an obvious optimisation
to some people, but which I think give you low cohesion
and tight coupling (ie 'code like jelly' - you poke it in
one place and everywhere else wiggles).

Regarding your specific example, most of my Access applications
don't have module level variables, but where required even I
use a form level flag for mbWasNewRecord. (as a matter of
interest, we name form-level variables as f... it works for us,
but I don't remember any justification).

But my advice for beginners would be to use a (visible,
disabled, unbound) checkbox Me.chkWasNewRecord instead
of mbWasNewRecord. BeforeUpdate/AfterUpdate code can be
awfully confusing, and anything you can do to help test
and debug is probably a good idea.

(david)
 
Perhaps he needs a demonstration of WHEN to use module
level variables...

Inside of a class module or form module:

Private mbIsConnected As Boolean
Private moDAODB As DAO.Database
Private moDAORS As DAO.Recordset

Public Property Get RSIsObject() As Boolean
RSIsObject = IsObject(moDAORS)
End Property
Public Property Get IsConnected() As Boolean
IsConnected = mbIsConnected
End Property

You could use the routine above to tell if moDAORS needs
to be destroyed. This provides a way to see if the object
was created outside of the class. It could have a use if it
is so needed. Other such things can be created as properties
to display the number of records in a dataset, without giving
access to the database... but then again, I'm thinking more
specifically along the lines of VB5/6 classes and objects and
there is more use for such things in VB DLLs.

Throwing more confusions in for the OP, maybe.

--
Jim Carlock
Post replies to newsgroup.

Well, yes... :~)

I was trying to keep it simple. In particular, I want
to discourage people from using module level recordset
and database variables, which are an obvious optimisation
to some people, but which I think give you low cohesion
and tight coupling (ie 'code like jelly' - you poke it in
one place and everywhere else wiggles).

Regarding your specific example, most of my Access applications
don't have module level variables, but where required even I
use a form level flag for mbWasNewRecord. (as a matter of
interest, we name form-level variables as f... it works for us,
but I don't remember any justification).

But my advice for beginners would be to use a (visible,
disabled, unbound) checkbox Me.chkWasNewRecord instead
of mbWasNewRecord. BeforeUpdate/AfterUpdate code can be
awfully confusing, and anything you can do to help test
and debug is probably a good idea.

(david)
 
Thanks, David.

Agreed completely about your rs/db variables, and will even confess to
trying that approach in version 1 of Access. :-)

The f (for flag) prefix was also common in the earlier days of Access before
there was a Boolean data type, so it's still in use.

The unbound hidden check box is okay as long as people set its Default Value
to No. Otherwise it can be Null, even if its TripleState property is set to
No.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Global variables! 4
Scoop question! 4
Declaring variables 9
module and global variable naming convention 3
How to access global variable EXPLICITLY 3
Using a variable 15
Naming Conventions 4
Why does variant not need set? 2

Back
Top