Defining Variable's in the Source Code?

Angelo_One

I was informed by another programmer that best practices for defining a variable when creating Include files for devices is to define the variable's in the Source code. Is this method correct? Because when I define variable's in the Source Code and then use them in the Include file the variable text stays black and does not change color. But code still compiles and functions. Any help would be greatly appreciated. Thank you in advance!

DHawthorne

You can define variables in either. I define variables that the INCLUDE needs in the INCLUDE, and the highlighting works fine that way. There are some quirks as to where to place your #INCLUDE statement in the main source, but unless it requires devices or variables defined in the main code as well, I put them right at the top of the file. Otherwise, I put them right below the section that contains dependencies they need. Also be sure to put all your DEFINE_<whatever> statements in the INCLUDE as well, so the compiler knows where to put that code. It doesn't care for most of them if you have multiples, just as long as you are careful not to wind up opening a new, for example variables section right smack in the middle of the constants section of your main code.

the8thst

Check this thread: http://www.amxforums.com/showthread.php?7836-Highlighting-Mod-Params

Include files and module files handle highlighting exactly the same.

ericmedley

**another plug for the Super Include **

PhreaK

A habit I try to stick to in NetLinx is define variables where they are needed. For example, if I've got an include that is handling say part of my system audio then I'll declare the variables I need for channel numbers in there. However, if there are variables that are being used across various parts of the system (eg. logical device id's) then I'll declare these in their own include.

That being said, always define your variables with the least amount of scope needed. If you have a variable which is only being used within a function or event, define it in there then pass variables around using your function arguments. This will help you avoid action at a distance, make debugging easier and greatly improve your code reusability.

--

Also, as a side note the term "source code" is generally used to refer to all of your uncompiled code. This includes both your *.axs and *.axi files in NetLinx. If you are referring to the file that shows under "Source" in the NetLinx Studio workspace tree a better way to communicate it may be your *.axs file or master file. End semantics nazi rant.