Declairing Vars - What's better?

[Stiletto]

Sups,
This question is buggin me and Id really like to the answer.
Lets say I have many functions and subs in my project, and i'm using For-Next loops in those functions/subs.
My question is, what is the best way to declaire the i var:
1. Decliare it once in General Declairations as public
2. Decliare it one by one as private in each function/sub
?
Tnx.

[peet]

Dim i As Integer inside each and every sub/function... never public counters ! U will mess up sooner or later

well thats my opinion anyways

[cafeenman]

I declare it in each sub or function. The way my code is written, it wouldn't matter, but that's just the way I like to do it.

Some people will say that it's possible for it to retain a value and screw things up, but in a For... Next loop, the start and end values are explicitly declared, so that really can't happen.

[Stiletto]

1 thing that is good is that if for example i write a function, and then i need to use it in a new project, i can just copy and paste it, without adding and changin the code.
But I mean as for the memory thing, what is better and what is takin less resources?

[peet]

u will go flat on your nose sooner or later .... just take a look at this EXCELENT sample

in form

Private Sub Command1_Click()
    test
End Sub

in a module

Option Explicit
 
Private i As Integer
 
Public Sub test()
    For i = 0 To 32
        MsgBox GetSomeData
    Next i
End Sub
 
Private Function GetSomeData() As String
    Dim s As String
    For i = 0 To 3
        s = s & i
    Next i
    GetSomeData = s
End Function

damn I'm creative

must be the worst sample ever, but I think(uhh hoping ) my point gets throuhg

[phinds]

the statement "in a For... Next loop, the start and end values are explicitly declared, so that really can't happen" is patently untrue.

If the for ... next section contains a function call, which it certainly could, and that function uses the same public loop index then you absolutely WILL screw yourself up.

Thus, NEVER use public loop counter. Peet has it right. If you write enough code over a long period of time and you use public counters, you WILL screw up eventually.

[Stiletto]

Creative like nuts! Good example man.
So ya sayin I should declaire it in each and every function/sub.
But what about the memory? What is better when it comes to memory if ne?

[cafeenman]

Originally posted by phinds
the statement "in a For... Next loop, the start and end values are explicitly declared, so that really can't happen" is patently untrue.

If the for ... next section contains a function call, which it certainly could, and that function uses the same public loop index then you absolutely WILL screw yourself up.

Thus, NEVER use public loop counter. Peet has it right. If you write enough code over a long period of time and you use public counters, you WILL screw up eventually.

Sorry for the bad info. I didn't think about it the way Peet used in his example which is why I don't declare public counters - something bad is bound to happen that you didn't think about. I think the memory savings are nil because the variable goes out of scope when you leave the sub anyway.

Personally, I think it's a waste of time to try to squeeze every last ounce of efficiency with things like this. Most people write the same string all over their apps instead of declaring one constant. That's the sort of thing that should be looked at because strings consume a lot of memory compared to numeric data types.

[peet]

Originally posted by Stiletto
Creative like nuts! Good example man.
So ya sayin I should declaire it in each and every function/sub.
But what about the memory? What is better when it comes to memory if ne?

never thought of that, and I'm never gonna

its a no topic today... go back 15 years, and I'd concider it

[Stiletto]

Originally posted by phinds
the statement "in a For... Next loop, the start and end values are explicitly declared, so that really can't happen" is patently untrue.

If the for ... next section contains a function call, which it certainly could, and that function uses the same public loop index then you absolutely WILL screw yourself up.

Thus, NEVER use public loop counter. Peet has it right. If you write enough code over a long period of time and you use public counters, you WILL screw up eventually.

Yea I was thinkin the way you and peet...but what is better when it comes to memory? is there a difference?

[MartinLiss]

I suggest that you never use "i" or any other one-character variable names. How much more trouble is it to use something like intIndex? A name like that is self-documenting in two ways in that it describes both its type and use. BTW, "i", "j" and "k" are left over from the old days of Fortran.

[peet]

you won't leave this alone will u ?

I think (well try to anyway) that declearing i's inside each and every sub is not more memory consuming than using one public i.
the reason is that the i's inside the subs and function are only "alive" as long as u'r inside the sub / function that its decleared. once your app leaves the sub / function the var goes out of scope and dies...

am I making any sense at all ?

[cafeenman]

Originally posted by peet
you won't leave this alone will u ?

I think (well try to anyway) that declearing i's inside each and every sub is not more memory consuming than using one public i.
the reason is that the i's inside the subs and function are only "alive" as long as u'r inside the sub / function that its decleared. once your app leaves the sub / function the var goes out of scope and dies...

am I making any sense at all ?

Yes... that's exactly what I said. It was the only part I got right, as a matter of fact.

[Stiletto]

Originally posted by MartinLiss
I suggest that you never use "i" or any other one-character variable names. How much more trouble is it to use something like intIndex? A name like that is self-documenting in two ways in that it describes both its type and use. BTW, "i", "j" and "k" are left over from the old days of Fortran.

Im always givin actual names to my vars. But as for I, J, K, i'm using them only in for-next loops when i need to count number of loops.

[peet]

Marty has a point. I have not gone that far down the road of self diciplin though

I use i,j,k,x..... have not started using æ,ø,å yet... that is something ?

often regret it thoug... when comming back to reread my excelent coding

[Stiletto]

Originally posted by peet
you won't leave this alone will u ?

I think (well try to anyway) that declearing i's inside each and every sub is not more memory consuming than using one public i.
the reason is that the i's inside the subs and function are only "alive" as long as u'r inside the sub / function that its decleared. once your app leaves the sub / function the var goes out of scope and dies...

am I making any sense at all ?

Yes, you right.

[peet]

Originally posted by cafeenman

Yes... that's exactly what I said. It was the only part I got right, as a matter of fact.

oh.. well a good thing cannot be said to often....yadiyadiya...

[Stiletto]

Sorry, some x-posting...

[peet]

Originally posted by cafeenman

... I think the memory savings are nil because the variable goes out of scope when you leave the sub anyway....

again..

sorry man .. didn't see that at first

[cafeenman]

It's cool. I wasn't trying to say "I said it first." I was just saying that I wasn't totally screwed up in my response. Just mostly messed up.

[peet]

Originally posted by cafeenman
It's cool. I wasn't trying to say "I said it first." I was just saying that I wasn't totally screwed up in my response. Just mostly messed up.

u explained in 2 lines what I used 9 lines to explain

I have to take some english lessons

[MartinLiss]

Originally posted by Stiletto

Im always givin actual names to my vars. But as for I, J, K, i'm using them only in for-next loops when i need to count number of loops.

Here are two examples of the same loop (the first one modified) from an app of mine. I think the second one is better because when I look at the code 6 months from now I don't have to remember what "i" is and I don't have to scroll up the code window to find out. It's a small difference, but I believe it's much more programmer-friendly.

For i = 0 To frmMain.chkOtherAttr.Count - 1
        If frmMain.chkOtherAttr(i).Value = vbChecked Then
            ' The TranslateXSDDataType routine converts the xml element
            ' types to a string with the Case values.
            Select Case TranslateXSDDataType(LCase$(gcolOtherAttr(i + 1).Name), _
                        TRANS_OTHER_ATTR)
                Case "TextType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i).Caption, _
                                                  frmMain.txtOtherAttr(i).Text)
                        If LCase$(frmMain.chkOtherAttr(i).Caption) = NAME_ITEM Then
                            '******* 1.00.001 #5 Start *******
                            frmMain.txtOtherAttr(i).Text = _
                                 CorrectCaseName("attribute", _
                                                 frmMain.txtOtherAttr(i).Text)
                            '******* 1.00.001 #5 End *********
                            If frmMain.tvwXML.SelectedItem.Text <> _
                               frmMain.txtOtherAttr(i).Text Then
                                ' The user has changed the name of the attribute-element
                                ' so we need to change the text of the tree node
                                frmMain.tvwXML.SelectedItem.Text = _
                                                      frmMain.txtOtherAttr(i).Text
                                gTree.AttributeName = frmMain.txtOtherAttr(i).Text
                            End If
                        End If
                Case "BooleanType"
                    If frmMain.optOtherYesNo(i).OptYesValue = True Then
                        Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i) _
                                                     .Caption, "yes")
                    Else
                        Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i) _
                                                     .Caption, "no")
                    End If
                Case "ComboBoxType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i).Caption, _
                                 frmMain.cboOtherAttr(i) _
                                        .List(frmMain.cboOtherAttr(i).ListIndex))
                Case "PosIntType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i).Caption, _
                                                  frmMain.txtOtherAttrPosint(i).Text)
                Case "FloatType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(i).Caption, _
                                                  frmMain.txtOtherAttrFloat(i).Text)
                Case Else
                    MsgBox ResolveResString(resUnexpectedData, _
                          "|1", TranslateXSDDataType _
                                (LCase$(gcolOtherAttr(i + 1).Name), _
                                TRANS_OTHER_ATTR), _
                          "|2", frmMain.fraMisc(fraOtherAttr).Caption, _
                          "|3", frmMain.chkOtherAttr(i).Caption), _
                          vbExclamation, _
                          ResolveResString(resValidationErrorTitle, _
                                          "|1", frmMain.fraMisc(fraOtherAttr).Caption)
           End Select
        Else
            Call oxmlElement.removeAttribute(frmMain.chkOtherAttr(i).Caption)
        End If
    Next

For intIndex = 0 To frmMain.chkOtherAttr.Count - 1
        If frmMain.chkOtherAttr(intIndex).Value = vbChecked Then
            ' The TranslateXSDDataType routine converts the xml element
            ' types to a string with the Case values.
            Select Case TranslateXSDDataType(LCase$(gcolOtherAttr(intIndex + 1).Name), _
                        TRANS_OTHER_ATTR)
                Case "TextType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex).Caption, _
                                                  frmMain.txtOtherAttr(intIndex).Text)
                        If LCase$(frmMain.chkOtherAttr(intIndex).Caption) = NAME_ITEM Then
                            '******* 1.00.001 #5 Start *******
                            frmMain.txtOtherAttr(intIndex).Text = _
                                 CorrectCaseName("attribute", _
                                                 frmMain.txtOtherAttr(intIndex).Text)
                            '******* 1.00.001 #5 End *********
                            If frmMain.tvwXML.SelectedItem.Text <> _
                               frmMain.txtOtherAttr(intIndex).Text Then
                                ' The user has changed the name of the attribute-element
                                ' so we need to change the text of the tree node
                                frmMain.tvwXML.SelectedItem.Text = _
                                                      frmMain.txtOtherAttr(intIndex).Text
                                gTree.AttributeName = frmMain.txtOtherAttr(intIndex).Text
                            End If
                        End If
                Case "BooleanType"
                    If frmMain.optOtherYesNo(intIndex).OptYesValue = True Then
                        Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex) _
                                                     .Caption, "yes")
                    Else
                        Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex) _
                                                     .Caption, "no")
                    End If
                Case "ComboBoxType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex).Caption, _
                                 frmMain.cboOtherAttr(intIndex) _
                                        .List(frmMain.cboOtherAttr(intIndex).ListIndex))
                Case "PosIntType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex).Caption, _
                                                  frmMain.txtOtherAttrPosint(intIndex).Text)
                Case "FloatType"
                    Call oxmlElement.setAttribute(frmMain.chkOtherAttr(intIndex).Caption, _
                                                  frmMain.txtOtherAttrFloat(intIndex).Text)
                Case Else
                    MsgBox ResolveResString(resUnexpectedData, _
                          "|1", TranslateXSDDataType _
                                (LCase$(gcolOtherAttr(intIndex + 1).Name), _
                                TRANS_OTHER_ATTR), _
                          "|2", frmMain.fraMisc(fraOtherAttr).Caption, _
                          "|3", frmMain.chkOtherAttr(intIndex).Caption), _
                          vbExclamation, _
                          ResolveResString(resValidationErrorTitle, _
                                          "|1", frmMain.fraMisc(fraOtherAttr).Caption)
           End Select
        Else
            Call oxmlElement.removeAttribute(frmMain.chkOtherAttr(intIndex).Caption)
        End If
    Next

[cafeenman]

I'm not even going to pretend like I understand that code.

[The Hobo]

Wow. That's a lot of code for a little point.

[MegaMan]

well i usually leave the single letter variables for integer counting. i j and k --and i use x and y for positioning.

[MegaMan]

Originally posted by cafeenman
I'm not even going to pretend like I understand that code.

how can you-- the code references a lot of subs and functions.. who knows what they do

[Stiletto]

Originally posted by cafeenman
I'm not even going to pretend like I understand that code.

Hehe

[Stiletto]

What I mean is that for counting number of loop, I use one letter counters like I,J,H. But when it comes to vars or to count something that i need to use it (say counting number of users logged on), i always use actual names.