Options
Did you say 20000 lines of code?
Spire_Jeff
Posts: 1,917
Nice suggestion. I like that! I try not to use AXI files for those reasons, but lately I've been starting to use them and can see how that'd be helpful. Good thinking!
You're the second programmer I have heard of that avoids AXIs... I would like to know what has caused this epidemic. I am just curious as to why you avoid includes? Is it only because of the searching? (If so, there is a find in files option that will search all files in the directory and sub directories if desired) Or are most of the programs you are dealing with fairly small?
I have on average around 20000 lines of code (counting blank lines for readability) in an average project. These lines are spread between roughly 25 include files. I can very quickly find the various sections of code that I need to deal with and more importantly, it is very easy to deactivate chunks of code quickly and completely by simply commenting out the #INCLUDE statements. I would find it very difficult to manage if it were all in a single file, although I would like the highlighting and auto complete
Jeff
0
Comments
I use both. I'd say it's something like 60% includes 40% modules.
Please don't take this personally, but it's just a question: what kind of programs average 20k lines of code? Is the length of code dependent on the number of touch panels? I average around 8k and as you can see from the definitions (constants, variables, etc.) just over half is actual code (data events, timelines, button events, channel events, and the define_program.) But, I also only deal with A/V, not the whole nine yards usually. I rarely do lighting & security; and never do HVAC. The includes from modules I just slap into the main program.
Perhaps this might be better off in its own thread than here. (Don't want to hijack it.)
First system straight out of Prog 1:
Around 90,000 lines. No DEV arrays, no multidimensional variables, etc... It was a lot of cut-n-paste changing just one item or so.... 8 Landmark DMS's with intercom, old viewpoint, 16 zones of audio/video, Landmark IR receivers with prontos, security, lighting, and a lot of hacking. Re-wrote what I could safely do in a couple of days and got it down to 44,000. Next big upgrade will see another huge reduction.
Second system after Prog 2:
Ah the power or Dev arrays... 10,000 lines of code. Similar system to above but with HVAC and 8400 instead of a viewpoint. No intercom..
Third big system after a lot of smaller ones and getting a Netlinx master at the house:
5800 lines! Only 5 landmark DMS's (have you figured out we started as a Landmark dealer yet??), but two 8400's, AXD5, CA10, TPI3.. Honestly at this point a new control device only adds about 100 lines of code at the most.
Working on our largest system right now and will have to post back a total when I'm done. I actually have enough time to concentrate on efficiency this time. This system has 14 CP4's with intercom, CV15, security, lighting, HVAC, kitchen sink..
So back on off topic, I'm starting to use includes for things that aren't needed all the time; light lists, security zones, basically setup info but not code. If the includes could be always merged in software for the auto-complete to work anywhere I would probably put everything in an include.
Kevin D.
Okay . . . umm . . . kitchen sink . . . connected to AMX? I've gotta hear this!
But anyway, back to topic (apparently a new topic created by Susan - thank you much!) You're right Kevin, the power of DEV arrays is amazing, then add in multi-dimensional variables, constants, etc. and you can have one heck of a flexible system. I think in the grand scheme of things, a programmer should have two main objectives: 1)Keep it super flexible, but solid. And 2) just make it work.
I'm not questioning Jeff's ability to complete a system or program one effectively, but I'm trying to understand what type of system really takes 20k lines of code. If it's a system that has 4 touch panels and standard A/V equipment, I'd say there are some areas that you could possibly improve on. However, if it's an EXTREMELY complex system, then I can somewhat understand. And if that is the case, I pose this question: how complex is too much? I'm a firm believer in giving the client what they want, but I'm starting to think there's a third unwritten rule in my book (along with the two above): just because you can, doesn't always mean you should.
(Sorry for babbling - I'm tired. Zzzz)
Paul
I controlled a toilet and bathtub once. That was fun!
A lot of the code that is written (in fact probably close to half of the lines of code) is simply setting the values in structures and various variables. There are also a lot of constants that I use for compile time options (such as max number of touch panels and what not. Also, some of my code is a little bigger because I have compile time directives in place for a couple of devices that we commonly use to allow me to switch between 232 and IP control easily (I was tired of rewriting and/or remembering to switch the includes... plus I was bored one day
I did not include modules, but I also use modules a lot as well. I use them mainly for comms, but there are a few I've written for portions of the UI. I would like to use them more, but some of the things I do with the UI and feedback don't lend themselves well to module use. Basically, it is easier at this point to just handle things in includes.
Jeff
P.S.
And thank you Suzanne for splitting this topic.
I'd imagine either you'd hate looking at my code, or I'd hate looking at yours.
this pretty much describes how I decide which is the most appropriate use of a module or include. Includes are more-or-less ways of organizing repeatative code that I'd otherwise just cut-n-paste from one project to another. In fact, the way it starts out is that I have a hunk of code to deal with device X. If I've done device X enough and it seems to be stable, I'll create an include, consolidate the code and put all the parts-n-pieces in the same file.
Modules tend to be things that stand alone or run in the background.
I have to admit, I don't know if Netlinx modules work like other programming modules. In other languages, modules truly do run as separate processes and are independent of the main program to which they are associated. It is possible for the main program process to be killed but the modules will keep running until killed themselves.
To me there are many things in Netlinx that are trying to be like or act like other languages but in reality are not. (Object Oriented comes to mind...) So, whether or not Netlinx modules are indeed like other programming environments, I tend to treat them the same. I actually don't use Data Structures much for this reason. In Netlinx, they don't make as much sense to me as say in C or whatever. All I find they do is make my conditional statements and math equations very long and hard to read. When I see a data structure in code I tend to start thinking in an object oriented way and look for the data being passed from object to object in a program but we're not really doing that. In my mind it's just putting lipstick on a pig.
Includes are nothing more than a way to organize your main code. I hear people sorta trying to think of includes in a 'module' way. that confuses me.
My programs average between 15K~25K lines of code on the high side. 5K~12K for smaller projects. We tend to do whole house systems. (A/V, Distributed A/V, HVAC, Security, Computers, appliances, pool/spa, etc...) Our commercial ones tend to be smaller.
the number of TPs doesn't really effect the program size too much for me. I tend to handle everything in DEV arrays anyway. It's more an issue of the number of sources needing control. Also, our clients tend to have more than one Home Theaters and/or TVs with distributed video. The more TVs, the bigger the program gets.
Using Mios or OEM equivalents also makes for a lot more text. I like it when the client uses a lot of interfaces but keeps them pretty much the same kind. When they start to mix and match user interfaces, my mood heads down hill.
Includes/Mods are a must in my closet.
To both: Organization is just a preference. At home, you'd look at my desk and say: "What a mess", but I know where everything is. I do understand everyone's point, but I'm not about to make that transition to that way of thinking just yet. Like I've shown, I think I keep it pretty organized with the multiple DEFINE sections, be it variables, constants, etc. I can add or remove entire sections quickly. I am trying to make things more modular so that when I go from job to job I have the ability to add a few lines here or there to get it going.
I usually start out with a self-defined template and go from there, which has most everything we deal with, and then I start removing anything we're not using and adding new stuff if need be. If it's something that is going to be used more often, I'll throw it into that template and when it's not being used - again, just take it out.
I think the biggest difference is that our systems typically comprise of the standard A/V (cable, sat, TVs, projectors, receivers, audio/video switchers, etc.), sometimes lighting, rarely security, and never HVAC, pools, hot tubs, kitchen sinks, toilets or bidets. Those systems are usually best kept to themselves for the jobs we do in my opinion. Although I'm always open to change, very little occurs with us.
The kitchen sink was more a reference to everything else, not an actual kitchen sink..
But if anyone ever asks, I'm up to the challange.
Kevin D.
I often say that if I'm ever asked to automate a toilet, I'll retire. What more could be done in this career if I automated a toilet??? At what higher mark could I aim?
What's so weird about that? You are having a party and before the guests show up you want to make sure there are no surprises in any of the toilets, so you flush them all from the comfort of your lazy boy in the theater. To me that's a huge selling point
Paul
We just finished putting a flush sensor into the toilet in a client's powder room. When the toilet is flushed it actives the second doorbell input and plays a flushing noise along with the blueman group throughout the home. This was at a client's request.
I programmed a toilet to flush 30 seconds after leaves the bathroom and only after 11:00pm and before 6am.
I was going to do this in my home (for demo purposes only
For me: this defines the definition of have lots of money.
It is a shame that we automate toilets now. Where are the modules AMX?