Declaration Style Opinion

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...