At the top, the project I did with XOJO has a lot and it was easier to give them logical names seeing them in a list and give them some sense of order at the same time, it would be a lot harder if they were mixed in with the code, like Albin I never use letters and numbers, usually I use camel case names
Interesting thoughts, actually!
As far as the conversation show, to this point, there seem to be no right and no wrong!
It more seems to be a personal kind of view, how you write the code.
Maybe a mix will do?
Sometimes the top is better, with better overview. But also, sometimes “when needed” may be better in other cases.
When it is used. It avoids cases where you are scrolling through code and have no idea what a variable is at the bottom. Then you have to wade through a sea of declarations to find it.
It’s also much easier to leave unused variables around when they are declared all at once. You DIM’d it at the top, wrote some code, later deleted that code, but forgot to delete the variable too. If the variables is dimensioned as part of the code, that can’t happen.
@Eli Ott, this works for just that purpose:
if true then // Scope
dim xyz as integer
xyz = 4 // ERROR - out of scope
I tend to declare them when I use them. Like Kem, I don’t like putting them at the top of the method because then I forget to remove them sometimes. I also like the scope control of declaring them where you use them.
Do what makes sense to you. That’s really all that matters. There’s no real right or wrong.
What I find myself doing more and more is making the shortest possible method to avoid scrolling in the code editor. Too much code makes it hard to read regardless of where the variables are declared. I also avoid having more then a couple of indents in code when possible. I’m a lazy programmer. I want the shortest, easiest to read code I can possibly write.
For the most part, I do identically to what Dave S outlined (minor exceptions like I use idx. jdx, kdx for indexing variables, etc.) including attempting to name variables something that I’ll recognize it for what it really is 6 months from now.
Of course, this goes to hell in a hand-basket when you have control sets. I have an emulated data grid in my current project where each data cell contains a text field. Some of these grids have 150 - 200 such cells … which precludes the usage of individualized, descriptively-meaningful names for each text field in place of a control set. In my case, let’s say I named the control set “txf” … so, for instance, I really have no way of knowing whether txf(99) is a volts, amps, watts, or whatever field without having a commented cross reference list of each cell’s contents somewhere close at hand in the code. In the end run, having the ability to use control sets in scenarios like that still trumps (by a long shot) whatever pain may result from the resultant inability to descriptively label each variable individually.