MarkT:
I'd say use blank lines and whitespace generously, keep layout clear and uncrowded for
maximum readability.
But yes, an empty function body doesn't need any extra blank-ness, its between the functions and sections
that blank lines are most appropriate. Just like any document, whitespace is excellent at conveying
structure to human readers, so use it.
I would say, use it "groupingly". For example I might change
digitalWrite( 9 , HIGH );
delay( 1000 );
digitalWrite( 8 , LOW );
digitalWrite( 9 , LOW );
}
void loop(){
to
digitalWrite( 9 , HIGH );
delay( 1000 );
digitalWrite( 8 , LOW );
digitalWrite( 9 , LOW );
}
void loop(){
to show functionality... we do some digital writes, then we delay, then more writes, finished block, now start a new function... etc.
While we're on the subject...
There are many other things that programmers do to make their code understandable. Use a standard indentation to clearly show the code blocks. Never put more than one statement per line. Place any brackets by themselves on a separate line. Give things descriptive names. Use descriptive variable names, for example "temperature" instead of "t". You can name numerical constants, pin numbers, variables and many other things in this way. For example, you can refer to a pin and an output level by number, like digitalWrite(3,0). But such a statement doesn't reveal anything about the purpose. digitalWrite(hornRelayPin, LOW) does. You can do that by declaring const byte hornRelayPin = 3; before setup() in your program. Many such names are already defined for you by the compiler and the Arduino IDE. Here are some:
#define HIGH 0x1
#define LOW 0x0
#define PI 3.1415926535897932384626433832795
Use them. There are many more. Use compiler math to compute values so you can see where they came from (or at least document them). For example, if you see the number 73, you would be hard put to explain the significance of it. But if you see "daysPerYear/5", it is obvious. One more thing. When you work on program continuously, you become familiar with it. So many things seem obvious even if they are not spelled out explicitly. But try looking at your own code six months later. It will be as if a stranger wrote it. So write for strangers, not yourself.
"ABVAR_1" doesn't tell you much, and the leading underscore makes it look like a system variable.