Tip: Write Modules

This tip is going to cover Crestron modules–specifically, writing your own.  As a new Crestron programmer, I shied away from doing this for years.  It wasn’t the style used by the other programmers I worked with, and I never felt that I had enough time between projects to revisit how I would have done it differently.  Over time, things change.  Our team of programmers changed, new styles replaced the old; I became more familiar with the tool set; I could turn around new work much quicker than when I started; and I found I finally had time to apply some retrospection.  Since I started incorporating my own modules into my programming, I’ve been able to increase my productivity even more and make the initial program almost bug-free.

Let’s discuss why you need modules to begin with.  Large programs are difficult to read.  SIMPL is already a strange language, but understanding everything that happens in a logic solution can quickly get out of hand.  For example, here is some of the logic to control the power state of just one projector:

This room has three other projectors, so we’ve got 3x duplicated logic cluttering up our debugger window when we’re trying to figure out why something doesn’t work.  We can simplify this using a module that we import four times–providing the same functionality, but hiding the mess.

Small programs are easier to read and to follow the whole solution end-to-end.  Therefore, we want to write large programs built from small programs and glue logic.  Everything within the small program works, has been tested, has been tuned.  The glue logic is usually simple, and often links large modules together where most of the processing is done.

Refactoring Code

You’ve done it!  You made it to the end of the project and the system works!…  For the most part…  As long as you don’t press buttons in this one particular sequence…  And if you give everything enough time to respond correctly.

This is referred to as freshman programming: doing just enough to complete the assignment.  But is the quality that of a professional?  Probably not.  It’s rough draft quality because that’s typically how we stumble across a working solution.

Now what you need to do–project schedule permitting–is look for the areas you duplicated logic.  Sometimes you have to generalize something enough to see that it’s really duplicated code.

Here would be a good place to stick an example.

Refactoring your code into a module means you can easily move the logic between programs.  When you fix bugs in one place, you will fix them in all places!

Code Reuse

Press and Hold is a module already available within the Crestron library, and it’s one I use quite a bit in my own programs.  The Crestron version is well-tested, so you’d be best to stick to using it.  But for the sake of creating a new module as an example, lets recreate it and see how we can use it to speed up development, simplify debugging, and rapidly deploy bug fixes.

Build Your Library

If you’d like to get started writing your own modules, I’ve got a few simple ones I’ve posted on my GitHub page.  They’re licensed using the MIT license, so you should be free to use them however you see fit.