Creating a Module
As we talked about in my last post about learning how to program, object orientedness is the name of the game when it comes to writing scaleable code that’s easy to update. Break your code up into little chunks that you can reuse. Figure out how to do it once, and you should (hopefully) never have to do it again. When you’re writing in line code, this means creating functions or classes that you can reference. In Crestron world, this means writing modules.I write modules for just about everything. If I have to do it more than once in a program, I write a module for it. This is for two reasons: consistency and updatability. Writing a module cuts down on copy/paste errors and ensures that you use the exact same logic everywhere. It also means that your code references one chunk of code, meaning one place to make changes. If you find a bug or get a requested change… just update the module, recompile and you’re good to go.
Writing a good module can be tricky. You want to cover all of your bases, but you also don’t want to make it so convoluted that it’s difficult to use. This is my basic process.
1. Sketch everything out before you start programming. There’s nothing worse than getting halfway through coding and realizing that you made a big mistake and the majority of what you wrote is now useless. I bought a roll of whiteboard contact paper and hung it around the desk in my home office. I will either diagram everything out there, or I’ll get some scrap paper and doodle it there.
2. Figure out what always has to happen. This is going to be the core of your module. The stuff that isn’t going to change. This is going to be the base of your code.
3. Figure out what only happens sometimes. This is where it gets tricky. How do you account for variations in rooms or systems? My general answer for this is to use a configuration file. I then use the values from the file as variables in my code. It can be as simple as a room name on a touch panel that can be changed without reloading code, or as complicated as different macros that depend on a room type.
Depending on how complicated the system is, I’ll use either an XML file or a JSON file. XML is harder to parse in the code, but easier for a technician to update, because they can use Microsoft Excel. I love being able to click in the bottom right corner of a cell and bulk update an entire column. If it’s a really complicated system, I’ll use a JSON file, because it gives me the ability to include complex data structures, like lists and dictionaries. I read in and parse all of my config files in Simpl#.
When it comes to having different macros depending on a room type, switch statements are your very best friend. If you don’t know what a switch statement is, there are countless examples of it on the internet. Most modern programming languages support it, even Simpl+.
4. Admit that your module can’t do everything. I like everything neat and organized. I want to be able to categorize all of the things. But even I will admit that there are always going to be some edge cases that won’t fit in neatly. It’s better to ignore the 1 percent of outliers in favor of a module that will be more efficient for 99 percent of your code. If you find yourself doing it over and over again, you might need a different module. But if you only ever do it once, you can let it be its own thing.
5. Test, test, test… then find someone else to test your code. You’d think that this one would go without saying. But you would think wrong. You need a neutral third party who will make sure that everything works the way it’s supposed to. It’s especially important to have someone who can see your blind spots and who doesn’t have a vested interest in saying, “ehhh, good enough.”
Obviously, this is just a high level view of what I do. The nitty gritty of it gets a lot more complicated. I hope that this article has helped you to think about how you go about writing your code. Please let me know what you think down there in the comment section!
Share This Story
More Stories Like This
Setting Up the AV Programmer for Success
Ask the Right Questions An AV system brings in many devices, audio and video signals that must be sent to a lot of destinations. This kind of chaos has to be channeled through a control system — a layout simple enough for any user to handle. All but the most basic AV projects need their […]
Study With Steph — Lesson 9: Mixed Signals
It’s time to talk about the way we connect. No, not with one another. I’m talking cables and the things at each end you use to plug them into stuff. If you’ve ever wondered what a Phoenix connector is, why wires and cables are NOT interchangeable terms and why building an AV rack the proper […]
Software Is Eating AV
“…software is eating the world.” — Marc Andreessen In 10 years or less, what was once the AV industry is going to be a be a footnote in the history of business technology, somewhere among the overhead projector and the fax machine. This hardware-centric industry we call home, this perpetual contest of who sells both […]