in Practice of Programming kernighan made a point about keeping variable names short
I offer this since you appear very unfamiliar with some of the ideas put forward here. One programming axiom is 'don't repeat yourself'. That is, don't write the same code over and over. If you find yourself doing this it's time to look into loops, functions, structures, classes, and so on.
However - when you're just starting out even some elementary concepts can take some time to become routine. My suggestion: get one, and only one cylinder working just as you want. Once this is perfected duplicate that code for the others (even copying and pasting) but also making sure to use unique variable names for each one - cylinder1_low_sensor, cylinder2_low_sensor, etc. At this stage don't worry about conserving memory or optimizing the code, just get it working. As you add each cylinder test frequently to make sure there are no unwanted interactions between cylinders.
IMHO, once you have a working sketch with this approach it'll be a lot easier to see why and where the programming concepts listed above can be applied.
.02
26 variables should be enough for anyone 
C++ is case sensitive so 52!
Only if half of them are constants
Standards have to be maintained you know
I often use variables with long names to make the code more understable when working on it (or for newcomers) but when finished or implemented it is probably best practice to make them as short as possible to improve processing speed. It is really only speed that would be the problem, the logic is not.
I take it that you posted this as a joke, or did you ?
I take it that you posted this as a joke, or did you ?
Well if the size of the code increases the speed will also deteriorate, not?
Too long
timeTheRedButtonGotPressedInMillisecondsSinceReset
too short
butMsec
Never liked
Button_Down_Time
so I guess make yourselves happy, or obey the master if you (still) working for one.
But I hadn't thought about how the long variable names woukd slow things down, just like I always forget that too much whitespace can lead not just to slower executuon, but undefined behaviour.
a7
I like that. But my next step would not be to cut/paste/edit N number of copies of the code, it would be to examine the perfect code and determine which of the variables it uses needs to be a "per tank" variable, and which are just local values like loop indexes or temporary calculations.
Then declare the arrays and modify the perfect code with the sprinklation that would be the addition of [ brackets ] and indexes.
Just have made too many mistakes duplicating (near duplicating) code myself.
a7
Never liked
Button_Down_Time
I completely agree, for readability the shorter might not be great but when its finished you could bring it back to BDT in my opinion. Just specify the shorter variable name used with //
No. It is conceivable that long variable names might under some circumstances cause an infinitesimal increase in compile time. But since C++ is compiled, they will not impact runtime at all.
What do you mean by "the code" ?
What is uploaded to the processor is not the code that you write in the IDE, it is compiled to binary code first and variable names are lost in the process so have no influence on the execution speed of the compiled code
No. It is conceivable that long variable names might under some circumstances cause an infinitesimal increase in compile time. But since C++ is compiled, they will not impact runtime at all.
I understand IDE code is not what is uploaded but the binary for a lengthy variable would also be larger? Else the binary would not be able to differentiate between SuperLongVariableNumberOne and SuperLongVariableNumberTwo or SuperLongVariableTwo. That is likely why you should avoid lengthy variables because checking the difference takes time. I am no expert on the compilation side of things but it seems the only option.
Agreed.
Nope. Once the code is compiled, the names are gone.
Agreed.
The variable names are reduced to an address and are retrieved later from that position. My mistake. Another day, another lesson.
aren't they in the symbol table of the executable (elf, not HEX)?
Apparently so.
If the Arduino C compiler is like the others, it immediately replaces your names with it's own token names and then goes on with the compile.