On naming variables, functions and constants

Hi all,

I find myself struggling naming variables, constants and functions I use.
It seems there is something like there is something going on with case depending on the type of object (variable, constant or function) but I can't quite figure it out...

I'm trying to write more readable and understandable code. Any advice?

Thanks,

How I work:

All constants that are #define'd are in capitals.

Everything else is camel case. Don't be afraid to use long names for functions and variables.

If you don't know camel case, it's multiple words joined together where the first word is all lower case and the subsequent words have an uppercase initial letter. That is how most Arduino functions are done. pinMode(), digitalWrite(), convertMySignalIntoCheese() etc.

Oh, and don't be afraid to overload your functions if you have two functions that do the same job on two different variable types.

Interesting.
Do you have a naming system as far as variables go? I often find myself struggling to find logical and organised variable names when several functions need values that are similar in purpose but should be kept as separate registers (most notably lastTimeEventOccured or table index counters)

You can use local variables in functions and the name stays inside the function. Local variables declared static will keep their values while just plain local variables are only good while the function is running.

If you get into C++ objects then you can pack data and code together as object-specific. I can have a widget class with size and color (and maybe a do() function) and make 2 widget objects each with its own size and color, widget_A and widget_B. I would get them as widget_A.size, widget_A.color, etc. Then I can address my variables by what they belong to and use widget_A.do() to make it work.

lastTimeEventOccured

In that situation I would name the event. lastTimeButtonAPressed, or lastTimeObjectPassedSensor3.

Thanks!

Longer the better - that's what copy & paste is for.

Oh, and keep the scope as tight as possible.

That way you can reuse generic names (like iterator, etc) in multiple places.

majenko:

lastTimeEventOccured

In that situation I would name the event. lastTimeButtonAPressed, or lastTimeObjectPassedSensor3.

Usually, you should be able to do better than that: Sensor3 presumably is a physical device of some type, its name should reflect it e.g. lastTimeObjectPassedCrankshaftHallSensor. I'd agree that that's getting uncomfortably long, but having variables distinguished only by number makes your code harder to follow/maintain.

wildbill:

majenko:

lastTimeEventOccured

In that situation I would name the event. lastTimeButtonAPressed, or lastTimeObjectPassedSensor3.

Usually, you should be able to do better than that: Sensor3 presumably is a physical device of some type, its name should reflect it e.g. lastTimeObjectPassedCrankshaftHallSensor. I'd agree that that's getting uncomfortably long, but having variables distinguished only by number makes your code harder to follow/maintain.

Obviously. Except I am interfacing to the Yang Fung Sensor3â„¢ :slight_smile:

I see. My apologies, that would indeed then be a perfectly cromulent name :stuck_out_tongue:

:roll_eyes:

The specific names are good and all but they can also lead to code like this:

int pinForVeeblefeetzerSensor1;
int pinForVeeblefeetzerSensor2;
int pinForVeeblefeetzerSensor3;
int pinForVeeblefeetzerSensor4;
int pinForVeeblefeetzerSensor5;
int pinForVeeblefeetzerSensor6;
int pinForVeeblefeetzerSensor7;
int pinForVeeblefeetzerSensor8;

which should be more like:

byte veeblefeetzerSensorPin[ 8 ];

And of course we all hope to learn at the company picnic just what a Veeblefeetzer does.

And of course we all hope to learn at the company picnic just what a Veeblefeetzer does.

I have a box of them here. I get them as free samples from Schnellblinkenlitze Companieret.

It's been mentioned but I though I re-iterate.

Constants should be in UPPERCASE, that way you can see at a glance that for example

for (i = 0; i < SOME_VAL; i++)

the number of loop iterations is not based on some variable and you don't waste time searching for code that updates that variable.

Long variable names are good, in general don't use no i, x, y, z etc, OTOH don't create descriptive variable names for the sake of it, I've seen

for (loopIterationCounter = 0; loopIterationCounter < SOME_VAL; loopIterationCounter++)

That's just plane ridiculous, for a simple value that's very local 1-char names are acceptable IMO.


Rob

That's just plane ridiculous, for a simple value that's very local 1-char names are acceptable IMO.

I'd go so far as to say preferred. The key, though, is consistency. Using i as a loop index throughout the code, rather than i one time, and loopIterationCounter another time.

GoForSmoke:
:roll_eyes:

The specific names are good and all but they can also lead to code like this:

int pinForVeeblefeetzerSensor1;

int pinForVeeblefeetzerSensor2;
int pinForVeeblefeetzerSensor3;
int pinForVeeblefeetzerSensor4;
int pinForVeeblefeetzerSensor5;
int pinForVeeblefeetzerSensor6;
int pinForVeeblefeetzerSensor7;
int pinForVeeblefeetzerSensor8;




which should be more like:



byte veeblefeetzerSensorPin[ 8 ];




And of course we all hope to learn at the company picnic just what a Veeblefeetzer does.

Shouldn't that be byte veeblefeetzerSensorPin[ 7 ]; for a eight element array as arrays elements start with zero?

Lefty

Shouldn't that be byte veeblefeetzerSensorPin[ 7 ]; for a eight element array as arrays elements start with zero?

Lefty

No. The value in the [] in the declaration is the number of elements, not the upper index.

PaulS:

Shouldn't that be byte veeblefeetzerSensorPin[ 7 ]; for a eight element array as arrays elements start with zero?

Lefty

No. The value in the [] in the declaration is the number of elements, not the upper index.

Thanks Paul.
The declaration and later utilization of arrays will always seem to cause me problems. But I usually figure it out during debugging. My sketches always require debugging. :smiley: