Tracking variables throughout a project

If you have a project that requires the maintenance of many properties and you are forever digging through the Xojo sidebar looking at how to spell a particular property name. Is it better to use a class or structure to reference the name of the variable.

There are a lot of things to consider when planning your code, and there’s no general correct answer except that global properties are inappropriate in almost every case. How many properties are you considering? What’s their scope? What do they do?

Personally, I prefix properties and variables by type so that I can use autocomplete to my advantage. Need an integer? Type i to filter the list and a couple letters from what the variable name probably is, and it appears in autocomplete right away. FWIW I never use structures for anything except declares.

To get a more detailed answer, you should answer those questions (whether to yourself, or here for advice).

Not to mention that you can use a Namespace (i.e. module) and make all properties Protected in scope. For example, if you had a modMyProject module and put Firstname as string and lastName as string and made both protected you’d refer to them in code as:

modMyProject.FirstName = “Bob”
modMyProject.LastName = “Keeney”

That way you can leverage AutoComplete. My motto is be lazy when you can. :slight_smile:

In that kind of case, I instead use:

Name_First As String Name_Last As String

Also, for DB projects, I use a mSQLite Module and like Bob and Tim says, I use meaningful variable names with restricted scope.

Namespace and Autocomplete are two of our best friends.

you arent the only one.

I have been using globals since my VB1 days. I dont really understand Tim Parnell’s response. Is there some kind of acute memory overhead to watch out for or is it some kind of discipline thing? While I appreciate style and art in programming, I dont want it to stand in the way of producing a killer program. If I am missing something, please set me straight.

There is a greater chance of introducing bugs when using global variables. The tighter the scope of a variable, the less chance of introducing a careless error.

The Xojo debugger is pretty painful when you want to examine the value of local and global variables at the same time … hunting up and down the variable list wastes a lot of time.
So if your variables are local/parameters, they are easier to keep an eye upon.

Off topic:
I have all but given up waiting for Xojo to add an ‘immediate window’ such as I enjoyed with VB (eg where you could type print szName in a small window)
Or ‘break when a variable changes’ (I can emulate it if I turn everything into a computed variable, but…)
Or ‘show value of a variable when you hover the mouse over it’
Or ‘copy the values from the variables list to the clipboard’

I fully agree with Jeff regarding his Off-topic remarks.

It shouldn’t be too complex to realize either. I remember
a simple, but quite effective, Delphi- look-a-like, Sybil,
for IBM OS/2 v. 4 (and Windows). It had all those features.

For my not too complex projects it proved to be as usefull
as IBM’s full-flexed VisualAge for C++ product. However, it
missed some advanced features like the VA’s built in Help-
facility that also allowed local testing of CGI-projects (like my
PDF-based math tests, with instantaneous HTML-result etc).

After IBM stopped with OS/2, Sibyl became obsolete, but the
complete source code (mostly Pascal) for the IDE became open-
source code, not the compiler/linker.

I was surprised then how seemingly complex features like Jeff
mentioned were achieved with relatively straightforward, very
good readable, and not too complex code.