Options
Organization question. Opinions needed.
kingpikey
Posts: 19
What is everyone's opinion on organization of code in a workspace? For example, how about creating Include files for each individual device, for encapsulation? I've also seen others make Include files for just DEFINE_DEVICE, DEFINE_CONSTANT, etc.
So, what does everyone think? I'm trying to decide on the best way to organize the code. I want to strive for the most modular, upgradeable, and maintainable code possible.
So, what does everyone think? I'm trying to decide on the best way to organize the code. I want to strive for the most modular, upgradeable, and maintainable code possible.
0
Comments
Use modules for all devices/UIs, and only use includes for code that will differ from job to job.
Paul
I will comment out the device declarations and timeline constants and move them into the main code with the other define devices and timeline just to keep things in order. I usually make variables and constants names specific to the device but when that doesn't make sense I'll comment it out of the .axi and leave it in the main file.
For the most part, if it's an 'under the hood' kind of thing that doesn't involve the main program at all, i'll put that into a module.
If it's essentially some kind of comm program from a device to the program (usually utilizing a virtual device) I'll put that into a module. I tend not to do much data passing in and out of modules myself. Most of my modules don't pass too much info.
Where I have routines that need to alter or use variables from the main program, or modular type things that always seem to need some kind of tweaking, I'll do an include. I have a Thermostat daily programming management include that seems to need one tweak or another from project to project. I tried making that a module, but ended up hating it. So, I changed it to an include.
I try to follow AMX's protocol on modules and how they work. I never put any user interface stuff in something that is a comm module.
This is one of those cases where I wish NS was a bit more like Visual Studio. I would just love a more robust navigation tree that doesn't actually care what file a bit of code resides in, but puts it all out there in summary, then opens the proper file when you want it.
This has been my finding as well. I will write modules that have the UI in them and some that don't depending on if its a user controlled device. Its really the only way to achieve any restriction of scope in Netlinx.
Variables, constants, function names etc. deifined inside the module and not passed in as a parameter to the module only have scope with in the module. So the same names can be used in the main code or any other modules and there isn't any need to worry about interaction even though the same names are used.
Modules append some sort of identifier to everything defined with in primarily to make distinction between instances of itself but also from the rest of the code. That's what the module instance identifier is for when you deifne your module.
Good analogy! Now I know what you were saying.
I agree with that thought. Within most of my modules, there are only a few variables that need to be shared with the main program, usually for status, etc. Most of the module variables can stay within. Another reason why I'm a module proponent.