Tips for Programming Variables and Function Names on Your BeagleBone

By Rui Santos, Luis Miguel Costa Perestrelo

Very few programs work without variables, and those that do result in huge messes. Even though variable names are arbitrary, it helps greatly to use self-explanatory names such as the following:

  • led to hold the name of the pin you’re using to light an LED, such as “USR3” or “P9_14”

  • state for a variable that holds HIGH or LOW

  • b for a BoneScript module object

  • button for an input pin to which a button is wired, such as “P8_12”

  • dutyCycle for a variable that holds the duty-cycle value of a pulse-width modulation (PWM) output pin

Imagine opening your code two months after you wrote it or handing your code to someone else. Would you or the other person easily understand what each variable represents? Unless you have an exceptional memory, we greatly recommend that you employ this technique in your code.

Additionally, you can use several conventions for variable and function names. You should adopt one convention and use it in all your programs to avoid some pretty annoying bugs. It’s quite common to declare a variable such as dutycycle and then write duty_cycle or dutyCycle somewhere else in your code.

JavaScript and Python are case-sensitive languages, so this entry would be an error. Although this type of bug is easy to detect, correcting it is an unnecessary waste of time. Following are the two most widely used conventions for naming variables:

  • Camel case: This convention is commonly used with the prebuilt functions of JavaScript, and it’s preferred when programming in BoneScript. All words after the first should have uppercase first letters. Using this convention, you’d enter inputPin rather than inputpin.

  • Underscores: This convention is used in the prebuilt functions of many programming languages, including Python. The words that compose the variable names are separated by underscores, like so: input_pin.

Some people prefer the underscores convention, the reason usually being that an underscore makes the most sense as a replacement for a space and makes the variable more readable. On the other hand, some people prefer the camel case convention because it’s faster to type (fewer keystrokes) and (in our opinion) looks more elegant. Follow the convention you prefer, or simply use the same one as the prebuilt functions of the language you’re using.

Following are some other conventions for naming variables:

  • index for a variable that indicates the index of an array or a list.

  • i for loops, j for a loop inside a loop, and k for a loop inside a loop inside a loop. Additionally, these variables are often used as indexes of arrays or lists when the instructions regarding the array or list are inside loops.

  • aux, tmp, and temp for auxiliary or temporary variables used to hold a value that will be placed in another variable later — you can’t swap the value of two variables without using a third, for example.

  • n and count for variables that count the number of times something happens.

Keep variable names short, but don’t shorten them so much that they become unreadable. Using tmp or temp for temporary is justifiable; using iPin rather than inputPin might lead to confusion.

Using names that somewhat explain the variable’s or the function’s task, as well as following conventions, makes changing parts of your code a faster process.

You don’t need to define a variable to deal with a pin’s state; you could use “P9_14” all the time instead of defining led = “P9_14”. If you decide to change it to pin P8_12 for whatever reason — such as if you notice that P9_14 is already being used for another task — you have to change all the lines of your code instead of just one.