comment 0

What’s In a Name?

Crestron SIMPL Windows uses “named signals” to wire up programming logic.  These signals are referred to as digital (either high or low), analog (a 16-bit number), or serial (a string of characters).  Color is used to distinguish what type a signal is–blue for digital, red for analog, black for serial, green for ambiguous–but otherwise, your only clue about what information a signal carries is left up to its name.

How then should you name your signals?  Let’s look at a few examples and see why they are good choices for signal naming.

[dev][mode][function]action

I was introduced to this convention while attending one of the programmer classes at Crestron.  You use brackets to delineate what device, mode, and function a signal drives.  The action gets tacked on at the end.  For example, a button on your panel may control the play function on the DVD player.  You might name your signal:

[dvd][transport]play

Brackets are easy to type–they don’t require you to press the Shift key–and they help you quickly pick out what a signal does.

room_dev_func_act

When you start programming multiple rooms within the same program, consistent naming is very important.  If you name your signals with corresponding room, device, function, they will all group together when you’re trying to debug.  Say you have multiple rooms with projectors, how do you isolate down to just the part of the program you care about?  You might try naming your signals like this:

cafe_proj1_power_on
cafe_proj2_power_off
cafe_tv1_input_hdmi1

When you’re watching in debugger, all you have to do is hide everything except the signals that begin with cafe_.  Copying the logic to another room that has the same layout is easy to do as well since you can copy and replace cafe_ with the next room, maybe lounge_.

Patterns to avoid

You want to make sure you don’t choose names that will spread functionality all over your program.  For example, say I use select_laptop1_presentation_source.  This reads well left to right, but later when we look in debugger, we may have our other sources scattered around.  select_doc_cam_presentation_source won’t be sitting next to our first signal, but it will at least be close by.  A better flow would be:

presentation_source_doc_cam_select
presentation_source_laptop1_select

This way, we always know where to go to find our presentation sources, and can quickly select between them if we need to.

Summary

Choose a pattern for your signal names that will cause them to line up easily for debugging purposes.  This will help make it possible to keep programs with 1,000s of signals organized.  The names should convey what device, mode, or action the signal controls.  Later I’ll discuss modules which provide a way to create reusable code, which can also hide a lot of noise created when debugging a running program.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s