Organization question. Opinions needed.

kingpikey

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.

a_riot42

kingpikey wrote: »

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.

Use modules for all devices/UIs, and only use includes for code that will differ from job to job.
Paul

vining

I like to use an inlcude for each device and use that .axi to instantiate one or more comm modules. Most of my modules/devices don't require instances for feedback (UI) at least not the way I write them so I pass the values back from the module and route it in the .axi to the appropriate UI device from the appropriate comm module. Basically .axi also acts as my UI module.

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.

ericmedley

I tend to start writing in the main file. Once I've organized how its going to work, I then migrate the whole mess over to an include or module depending upon how I went about doing it.

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.

DHawthorne

I used to try make my modules so that they can be installed completely with an include file ... so the include has everything the module needs to load and run. However, it tends to make it a bit of a nightmare looking for conflicts with device numbers, ports, etc. So I am moving away from that to having everything in the main code in terms of variable and device declarations, etc. I am trying nowadays only to use include files for global declarations that multiple modules may need as well as the main code.

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.

PhreaK

Personally I've been getting into the habit of having one include per device, include's for logical, reusable groupings or functions (ie system power.axi holds system startup, shutdown and timeout functions and related timeline events), however I keep all of my button events and feedback in my master axi so that I can look in one area to get a complete overview of what's going on there, or in the case of multiple tp's / interface devices, one include for each. Additionally for each device I create a structure for all it's state info which I then import into a main system status structure.

TurnipTruck

I'm all modules, one per piece of controlled hardware. Unlike others, I integrate the UI into the same module as my device comm. I like modules because I never have to worry about variable name conflicts, etc. Adding a device to a system is as simple as a define module statement.

a_riot42

TurnipTruck wrote: »

I'm all modules, one per piece of controlled hardware. Unlike others, I integrate the UI into the same module as my device comm. I like modules because I never have to worry about variable name conflicts, etc. Adding a device to a system is as simple as a define module statement.

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.

TurnipTruck

What is restriction of scope?

vining

It's like what ever happens in Vegas stays in Vegas.

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.

TurnipTruck

vining wrote: »

It's like what ever happens in Vegas stays in Vegas.

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.