Declaration Style Opinion

Hi everyone,

I want to ask for your opinion. Below there are two sub procedures. Both does the samething. Only difference is the declaration of the variables. Does it matter if I declare a variable on the fly or is it more appropriate to declare all variables at the beginning?



Method1

Code:

---

Sub Main()
  Dim str_Data As String
  str_Data = "Method1"
  MsgBox str_Data

  Dim int_X As Integer
  int_X = 1
  MsgBox int_X
End Sub

---

Method2

Code:

---

Sub Main()
  Dim str_Data As String
  Dim int_X As Integer
 
  str_Data = "Method2"
  MsgBox str_Data
 
  int_X = 1
  MsgBox int_X
End Sub

---

I think it doesn't matter. Before compiling, vb automatically moves the lines to the beginning.

a matter or preference:

From what I've read, it's standard programming procedure (whatever that means :)) to declare all variables at the top of procedures.

All the best.

Thank you Oetje, HeSaidJoe and OneSource. I have a very unorthodox way of programming and was just concern about the performance of the program.

Thank you again.

Nope, it doesn't matter where you declare it.
But it's a good idea to declare them at the top 'cause otherwise you'll get confused wheter you declared it or not.
But like HeSaidJoe said, it's just a matter of preference
But I also like declaring strings and integers like this

Code:

---

Dim MyStr$  'Instead of ... As String
Dim MyInt%  'Instead of ... As Integer
'I think it looks neet, simple and professional :)

---

I didn't know that variables could be dimmed like that. :)

Have you ever tried to work your way through code that is written in an unorthodox way? Couple that with converting legacy VB3 apps to VB6 and the headache potential is huge . . .

Quote:

---

Originally posted by OneSource
I didn't know that variables could be dimmed like that. :)

---

I didn't know that variables could be declared like that.

Quote:

---

Originally posted by Megatron

Quote:

---

Originally posted by OneSource
I didn't know that variables could be dimmed like that. :)

---

I didn't know that variables could be declared like that.

---

What's the big deal? :confused: Just a little VB slang! :)

Your style does the job Jop but I am use to Hungarian Notation. I think most people at my company use your style of notation.

Thanks everyone!

Hey Nitro, your question made me wonder about the following situation:

Code:

---

Private Sub Form_Load()

    Dim a As Integer
   
    For a = 1 To 10
        Dim b As Long
       
        b = b + 1
    Next a
   
    Debug.Print b
   
End Sub

---

Does anyone know? Does b get dimmed once or ten times in this code?

Just wondering.

As we all now, vb's garbage collection is not the best when it comes to fairly complicated objects. This is why you should not declare objects 'on the fly' in vb. Declare them in the morning, and clean them up last thing before you go to bed.


Here's a question:

What happens to an objects passed byVal to a function,
when the function loses scope? i.e.

public sub WhereDidMyMemoryGo(Byval oAnyOldObject as object)
'/ some stuff
end sub


You could make this question harder by asking what if the function is in another apartment, thread, or process (who's doing then marshalling;-) ??



td.

Hax,

it gets declared 10 times. VB may well manage the memory for this and just reuse the same space, but get into habits like this and the world may stop . . .

If you want some really sloppy code, don't declare them at all and let VB hand you a big fat Variant...

Jop,

only problem with Dim int%, str$ is readability - if you do not know the post fixes it can be confusing - As String is unambiguous.

As a matter of style I always declare my intentions at the start...;)

Cheers,

Paul.

From a style and maintenance point of view, you should declare you variables at the beginning of the procedure with meaningful names, preferably including some form of hungarian notation. Don't use the postfix declaration, cos it is a dog to maintain. Don't call your variables x or a - use something decent.

The only exception for that is if you need to declare an object variable that is memory hungry, or takes while to initialise, and is only used in certain conditions:

eg:

Code:

---

Private Sub Process()
    Dim lstrText as String
    Dim llngLoopCount as Long
    Dim lobjItem as SomeObject

    'Do some stuff

    For llngLoopCount = 1 to 100
        lstrText = "XXX"
        lobjItem = GetItem(llngCount, lstrText)
        If lobjItem.Err = 12345 then
            'This is a very rare case (ie. the error is rare)
            'and needs a special handling mechanism
            Dim lobjSpecialObject as SomeLargeObject
            lobjSpecialObject.HandleError
            Set lobjSpecialObject = Nothing
        End If
    Next llngCount

End Sub

---

The above example ONLY declares the SomeLargeObject, which takes a long time to initialise (for whatever reason) if the condition where it is used is required. This means that the process time for the loop when an error doens't happen is reduced, and the memory the SomeLargeObject requires is not used unless absolutely required.

Having said that, I would only recommend using that conditional declaration approach in special cases, and only for large memory or init-time intensive object. I wouldn't use it for any sort of standard data type - they are fast to create and use very little memory.

Even if you are only coding by yourself and not in a team, it's good practice to make sure you code conforms to some standards, cos when you do end up working in a team environment, your life will be that much easier, and you code very easy to maintain, which makes everybody happy. There is nothing worse than having to maintain spaghetti code. I know, I've been there many times. :)

- gaffa

(I hate editing for typos)


[Edited by gaffa on 11-03-2000 at 06:03 AM]

Gaffa,

I was under the impression that VB compiled then ran and so would read all the variable declarations independently of whether they are in an If..Then..Else statement. Consequently the memory would still be in use.

I am willing to be corrected - for as MicroSoft have proved recently 'nobody is infallible'

To be honest gravy boy, you could be right... I'm not actually as sure now that I think about it. I do seem to recall reading about this technique somewhere, but it is entirely possible I'm wrong. I jsut spoke to another guy I work with, and he's is also under the impression that conditional declarations work. But.......who knows.

Probably worth some further research. I very, very rarely use the technique though...

- gaffa

Technically it does not matter where you declare a variable.
It is not initialised until the first time it is used.

If you declare a variable in a loop, you are still only declaring it once.




td.

At'll do me . . .

Hi td,

You are partially correct, but - it depends where the variables are - if they are declared in a BAS module, for instance, then memory will be allocated and the variables initialised to their default values on the Application starting up. They will retain memory until the application exits even if they are never used!. Variables in Forms and Class modules share the life of that form or class. Only Dynamic local variables (i.e. declared within a procedure) will not exist until the procedure is run. A Dim will allocate memory and set the value as default - the variable does not have to be used to take up memory.

Cheers,

Paul.

Paul,

I know, i was only pointing out about the about the location in a looooooooop.


I take it your a city lad, how's Fortis.



td.

Hi td,

You could say Fortis is tumblingdown:D

Where are you?

Quote:

---

It is not initialised until the first time it is used.

---

that made me believe you were not aware of the memory implications of Dim and its default values etc.

Quite right about the loop.

Sorry for dissin' you.

Cheers,

Paul.

Well i suppose technically i'm at CSFB, but i think most of the time i'm just off in my own little world...

Oh, and just got back after a few bevvies at lunch. Best time of the day, that post liquid lunch feeling ;-)



td.

Wayhay! Same as meself . . . .


I often find that if you go out drinking with the management more gets done in terms of man-management . . .

OK gravyboy and tumblingdown - we obviously cannot pass up the chance to have a career enhancing beer (or seven). However I am assuming that you are down in Canary Wharf - could be tricky.

Send me a mail with some contact details if you fancy some liquid refreshment.

mail me at [email protected]

P.S. Sorry for hijacking your thread Nitro

Cheers (or should that be Bottoms Up!)

Paul.

Quote:

---

Oh, and just got back after a few bevvies at lunch. Best time of the day, that post liquid lunch feeling ;-)

---

Unfortunately I have just left the Marble Arch in Manchester and may be a litte late for the beer . . .

gravyboy,

according to your profile you are with Centrica (I had assumed that when you said 'same as meself', you were talking about CSFB not the beer (how stupid can I be....),

however, getting back to the point I used to work for BG before it split into a million pieces...

VB World; British Gas; Beer spooky coincidences, or what...






What (hehehe)

and Yeh I have had a few beers meself...

Cheers,

Paul.

Paul, mail sent.

td,

There's another BG bod around here Gary.Lowe . . . ex BG anyway!

btw, now beating you by 2 posts hehe.

td

td - Excellent news...

but I think...

I have posted...

one more than you. HEHEHEHEHE

Cheers,

Paul.

****, beating me.






oh no, your not afterall. would you look at that.


td.

But I'm just removing the automatic "email notification" option for me for this post. :)

sorry mate, we'll stop.

Oi! Paul, pack it in! i said No!


td.

Not me guv.

I was over in Chit-Chat wondering about CHICKEN.

BTW td - you are sick (can't wait for the beer) ;)

Paul

P.S. Sorry everybody, we'll stop now.

Just some more automatic data type definition characters
I'm not sure if it actually speeds up your project.

Code:

---

dim something$ 'string
dim something% 'integer
dim something& 'long
dim something! 'single
dim something# 'double

---

Paul Bousa

Also try this,


Dim something As LOADSOFBEER


I always find this to be pretty effective, the speed increase in a For..Next for example increases by about a factor of ten.



td.

err, before anyone has a go at me, i'm sorry if you think that was in the wrong forum.

What can i say ;-)



td.

I realize the difference between Long and Integer, but I've gotten into the habit of not using Integer, ever. Will using long instead of integer hinder the performance of my computer or programs in anyway? Just curious.

I also use long instead of integer.

I read somewhere that a 32 bit machine internally always uses long (=32 bit number)

I think it will be quicker using long instead of integer. I'm not really sure about this.

In an attempt to get back to the original subject, how about variable naming conventions.

I prefer to use single character prefixes i.e.
Dim sText as String
dim iNumber as Integer

But it gets confusing between byte and boolean and string and single.

Anyone have a good rule of thumb?

Tell you what i really hate when I'm reading other people's code? When they use all the postfix letters to declare their variables!

Code:

---

'This looks ****, and is confusing to read and maintain
Dim MyStr$
Dim MyInt%

'This is better!
Dim MyStr as String
Dim myInt as Integer

---

Point made. Let us banish the unruly Hungarian notation to VB hell forever!

Laterz

Quote:

---

Let us banish the unruly Hungarian notation to VB hell forever!

---

Just FYI, Hungarian notation refers to PREfixing a few letters to the front of variables to describe their type, i.e.:

Code:

---

txtName ' This is a textbox
lblName ' This is a label

---

Click here for more on this from microsoft support.

I haven't read every single post, so if this is redundant I apologize.

At the top of each procedure/function I declare all the variables for that particular sub/function. Simple enough.

I handle variables that are global throughout the entire project a little differently. In a standard code module, I create a public data type called "GlobalVariables" I then declare a public variable G as "GlobalVariables", like so:

Public Type GlobalVariables
UserID as String
UserName as String
UserLocation as String
..
..
End Type

Public G As GlobalVariables

Using this method, anywhere throughout the code you can reference a global variable using "G.<variablename>...bla bla bla" It makes it nice because of the intellisense menu that pops up each time you type "G." If you forget a variable name you can pick it from the list etc.

But is using this method less efficient because of the type structure? What makes it nice is that you can nest type structures withing the GlobalVariables type. Within GlobalVariables you can have a variable called "Cust" of data type "Customer" which is a Type consisting of the variables "FirstName," "LastName" So you would reference the customer data by using "G.Cust.FirstName" etc. The method works great. I've also been doing the same for variables that are public within a form, assigning the variable name "P".

Does anyone know if this reduces efficiency having to make multiple references to get to the data?

The short answer:
I don't know how this affects efficiency.

The long answer:
From a "programming practice" point of view, it is good practice to encapsulate related data into a single structure. Encapsulting types within types is not inherently bad, either. One thing to think about is that many items that warrant creating a user-defined type for can be made into classes instead. This kind of encapsulation is good practice.

It looks like that is what you are doing in your example; all you would have to is rename your type "User" instead of "GlobalVariables".

It is generally considered bad programming practice to simply wrap a bunch of unrelated data into a type because it's "easier".

That's my opinion...