Solved: "Integer" vs "Long" in For...Next Loops

[Cyberdude]

In his terrific article on making macros faster and shorter, johnske mentioned that the index variable in a For...Next loop should be dimensioned as "Long". I have always had the habit of making the variable "Integer" because it takes less memory. That's probably not a big issue, but why not? Most of my loops have a max number of iterations that never approach the overflow limit of integer, so it just seemed logical to use integer rather than long. So, John, did you really mean that loop variables should always be long??
I've also had a habit of making row number type variables type integer. Upon thinking about it, I can see where that is clearly illadvised. They should be declared as long, and I'm revising old code to reflect that observation.

[Bob Phillips]

In his terrific article on making macros faster and shorter, johnske mentioned that the index variable in a For...Next loop should be dimensioned as "Long". I have always had the habit of making the variable "Integer" because it takes less memory. That's probably not a big issue, but why not? Most of my loops have a max number of iterations that never approach the overflow limit of integer, so it just seemed logical to use integer rather than long. So, John, did you really mean that loop variables should always be long??
I've also had a habit of making row number type variables type integer. Upon thinking about it, I can see where that is clearly illadvised. They should be declared as long, and I'm revising old code to reflect that observation.

You should always use longs because the OS will convert integers to long and back again, very inefficient.


http://msdn.microsoft.com/library/de...rdatatypes.asp
The Integer, Long, and Byte Data Types

[johnske]

You should always use longs because the OS will convert integers to long and back again, very inefficient.


http://msdn.microsoft.com/library/de...rdatatypes.asp
The Integer, Long, and Byte Data Types

Exactly...

...Traditionally, VBA programmers have used integers to hold small numbers, because they required less memory. In recent versions, however, VBA converts all integer values to type Long, even if they are declared as type Integer. Therefore, there is no longer a performance advantage to using Integer variables; in fact, Long variables might be slightly faster because VBA does not have to convert them.

[BlueCactus]

You should always use longs because the OS will convert integers to long and back again, very inefficient.


http://msdn.microsoft.com/library/de...rdatatypes.asp
The Integer, Long, and Byte Data Types

Learn something new every day!

[johnske]

Learn something new every day!

I hope so! Life'd be pretty boring otherwise

[MWE]

You should always use longs because the OS will convert integers to long and back again, very inefficient.


http://msdn.microsoft.com/library/de...rdatatypes.asp
The Integer, Long, and Byte Data Types

The msdn article suggests that the Integer to Long conversion (and back again) is for all Integer instances, not just in loops. Thus I conclude that one should just stop using Integers in general; and use Longs instead.

[Ken Puls]

The msdn article suggests that the Integer to Long conversion (and back again) is for all Integer instances, not just in loops. Thus I conclude that one should just stop using Integers in general; and use Longs instead.

That was my interpretation as well. I haven't used an integer in quite a while now.

This gives rise to one of xcav8r's pet peeves though

[vba]Dim i as Long[/vba]

[Bob Phillips]

That was my interpretation as well. I haven't used an integer in quite a while now.

This gives rise to one of xcav8r's pet peeves though

[vba]Dim i as Long[/vba]

Why? I despair of people who insist on defining the data type as part of the name. To my mind, the name should indicate what the purpose is, nit what data type is. A decent coder will be able to determine its datatype either intuitively, or from its (lack of?) declaration. Much more useful to know its purpose to my mind. I use

iName is an index
cName is a count
nName is a number/accumulator
mName class member
etc.

The worst in my book is strSomeName, what a waste of 3 characaters. Especially when you get things like strLngFileNme so as to keep it down.

[Ken Puls]

LOL!

I've seen this discussion before somewhere...

Personally, I do preface with a datatype, but that's my style. I tend to use the following:

sName is a name
lRow is a row
cBar is a commandbar

I'm not saying that they're always logical, but they serve my purposes. They can quickly be indentified as standing apart from the object model, and are meant to save me typing. I try to make them a readable form of shorthand as well.

Honestly, I can't say that I've ever been confused and accidentally tried to jam one of my strings into a long "hole" after I figured out that the distinction is important, but then it is supposed to make it easier for someone else to read.

[Zack Barresse]

In general, regarding iterating loops, I use an i variable as it's inconsequential to the outcome nor does it need any explanation by myself to tell what it is or define it's purpose. Besides that, naming conventions do help, I believe.

As far as prefacing with data types, I find myself doing that more and more often. Such as ..

[vba]Dim rngLook as Range
Dim rngFind as Range
Dim blnWasOpen as Boolean
Dim strMsg as String
Dim dtStart as Date
Dim dtEnd as Date
'.. etc, etc..[/vba]

I've seen some people get crazy with their naming conventions. I also believe that another aspect to that is if you are coding something in a relay or handoff type situation exists. If you are creating something for another person or company that they are to work, maintain and troubleshoot, it should be very well documented and ver easy to read/decipher, which may include changing some named variables used.

At the end of the day, I think it all boils down to whether the code works as well as it can for it's intended purpose.

[Bob Phillips]

LOL!

I've seen this discussion before somewhere...

Am I repeating myself

[Ken Puls]

Am I repeating myself

Possibly, but I actually can't remember. I know that I've been involved in one of these discussions before. I can't quite remember the players though...

Maybe I read too many posts or something... ... Nah!

[johnske]

Am I repeating myself

Not really Bob, It's just that this topic has appeared several times in the past and usually generated heated debate.

As the 'odd-ball' on the board, I feel I should state my case:

I tend to use descriptive variables, but not decriptive in the sense of a description of their 'type' (what's the point? They are, after all {or should be} already declared as a type at the head of your code). Hungarian-type notation really makes me feel I'm being whacked on the head with it every time I see the variable - Puh-lease... I DO take the time to read & remember the variables declarations before trying to read the code, there's no need to repeat yourself.

Any name I use is not always as a description of the variables role in the code either - the code should be fairly transparent and the role obvious, the name is more of a description of how it relates to the data on the spread-sheet - this usually means the name reflects the column heading with only sometimes something added that may clarify its role in the code.

In effect, I often use variable names in the same sense that others may use Range Names and thus avoid using Range Names altogether. For example, when doing a very large procedure for (say) handling a payroll I may tend to use something along these lines:[VBA]Dim WorkersName As String, StaffName As String, HomeAddy As String,
Dim IDnumber As Long, HoursWorked As Double
Dim WorkerPay As Double, StaffPay As Double, ProfitMargin As Double
Dim SickPay As Double, HolidayPay As Double, LeaveLoading As Double
Dim TaxRate as Double, CompanyTax As Double, PayRollTax As Double
Dim AllWorkers As Range, AllStaff As Range, HomeAddies As Range[/VBA]When using abbreviated names I try to follow the rules of mathematics where the early part of the alphabet is reserved for constants (while noting that i, j, and k have a special role in vector notation) the 'middle' part (L, M, N {N is for number - get it?} O, P, Q) can be variables or constants, and the last part, r to z is reserved for variables.

But, as Zack said, the main thing is...

At the end of the day, I think it all boils down to whether the code works as well as it can for it's intended purpose.

[Bob Phillips]

I tend to use descriptive variables, but not decriptive in the sense of a description of their 'type' (what's the point? They are, after all {or should be} already declared as a type at the head of your code). Hungarian-type notation really makes me feel I'm being whacked on the head with it every time I see the variable - Puh-lease... I DO take the time to read & remember the variables declarations before trying to read the code, there's no need to repeat yourself.

Any name I use is not always as a description of the variables role in the code either - the code should be fairly transparent and the role obvious, the name is more of a description of how it relates to the data on the spread-sheet - this usually means the name reflects the column heading with only sometimes something added that may clarify its role in the code.

I agree with most of what you say, but I use a role prefix for a real purpose. Whilst I agree that we should know what role a variable serevs when we create it, I add that role for other times, so as to make sure that I don't misuse the variable somewhere else. For instance, a poor example maybe but hopefully it will illustrate my point, is a variable called TopLevel. This could be a flag to indicate that the data is or is not at the top level, or could be the key of some top level. Without some role identifier, it could be misused.

But, as Zack said, the main thing is...

At the end of the day, I think it all boils down to whether the code works as well as it can for it's intended purpose.

This is the one I really disagree with, don't forget it has to be maintained, maybe even by somebody else.

[johnske]

I agree with most of what you say, but I use a role prefix for a real purpose. Whilst I agree that we should know what role a variable serevs when we create it, I add that role for other times, so as to make sure that I don't misuse the variable somewhere else. For instance, a poor example maybe but hopefully it will illustrate my point, is a variable called TopLevel. This could be a flag to indicate that the data is or is not at the top level, or could be the key of some top level. Without some role identifier, it could be misused.

If you read my last sentence in the quote you'll see I'm not in disagreement wth that principle, but I only apply it where necessary - but not as a matter of course - and for variables relating only to the codes operation.

The main thing is that when I'm in the VBE window reading code I really hate having to constantly flick back and forth to the main window to see what the code is referring to - where appropriate it's simpler to just modify the name of the column headings and use it as your variable name to avoid all that.

This is the one I really disagree with, don't forget it has to be maintained, maybe even by somebody else.

I agree about maintainence, but regardless of what notation is used every coder has their preferences and we just have to learn to read it.

One way around this is: E.G. When reading someones code that's written in Hungarian notation I find it very very difficult to concentrate on the flow of the code while being constantly whacked over the head with its' type, so I first copy it to a code pane in the VBE window and do a mass find and replace of all the variables to make it easier to read. (The only problem to doing that is when single letters such as i, j, x, y etc. are used frequently )

[brettdj]

Should we re-open that range name debate as well?

I've never really understood why the naming convention gets people so riled, each to their own as long

[BlueCactus]

Nice troll, Cyberdude!

When I get my own naming conventions somewhat consistent, maybe I'll have something more constructive to say.

[johnske]

Should we re-open that range name debate as well?
...

Don't you dare! That went on forever...

[brettdj]

True - and I currently have the last say.

[Cyberdude]

Not that it matters much, but my pet peeve is trying to read subscripts with lowercase letters, especially "i". For some reason the lowercase letters seem to get lost between the parentheses and a lower case "i" doesn't always look like an "i"... it might look like an "l", depending on the font being used. My favorite loop variable is "N". Easy to see everywhere it's used. Next I use "K", then "J".