next topic »

[on:]

I notice that both of these lines work:

Code:

boolean pressed = (digitalRead(3)==HIGH);

boolean pressed = digitalRead(3);

I would assume that the first is more correct unless HIGH and LOW were interchangeable with true and false in which case the second line would be a better way to write it.

Which is correct? or more correct? Can I always trust that second one to work?

Thanks

[Reply #1 on:]

Boolean FALSE is zero, anything else is TRUE, so you can use any value that resolves to one or the other in a boolean test.  The answers from your examples depend more on how the switch is wired than the program statements used.  For instance, a floating switch input is not guaranteed to be in one state or another for any length of time if the switch is open.

[Reply #2 on:]

A boolean is simply a byte sized variable. True is non-zero. False is zero.

HIGH and LOW are defined as 1 and 0 which match the definitions of true and false.

So, either f your statements will work, under some circumstances, although I prefer the first one. It explicitly says that you want to compare the reading of the pin to HIGH.

Think about what the second statement would mean if the internal (or an external) pullup resistor is used. When pullups are used, LOW (false) mean pressed.

[Reply #3 on:]

Definitely the first one is better as it is the most explicit.

Bob Martin (from the book Clean code) would say "use descriptive names where possible" and add spaces around the ==

boolean isButtonXPressed = (digitalRead(ButtonX) == HIGH);  

This makes the code self documenting

[Reply #4 on:]

Code:

boolean pressed = (digitalRead(3)==HIGH);

You don't need the brackets, so:

Code:

boolean pressed = digitalRead(3) == HIGH;

I prefer that, because for one thing, in a lot of cases, where you use the pull-up resistor, pressed would be:

Code:

boolean pressed = digitalRead(3) == LOW;

Second, semantically, it is "true" you did a digital read, but did it return HIGH or LOW?

[Reply #5 on:]

Some people advocate writing code like   

Code:

boolean state = ( HIGH == digitalRead(3) )

The reason to do this,  is that you will get a compiler error if you type the wrong number of equals signs.

[Reply #6 on:]

Some people advocate writing code like   

Code:

boolean state = ( HIGH == digitalRead(3) )

The reason to do this,  is that you will get a compiler error if you type the wrong number of equals signs.

Personally I err on the side of extra brackets.  Yes, it may look a little more crowded, but you can then be 100% certain what order things are going to happen in.  Some of the order of precedences can be a little grey - if you have two operators that have the same order of precedence, which one will happen first?  And can you remember the order of precedence of ALL the operators off the top of your head?  Thought not.  I have a good memory, and I can't - only that * and / happen before - and + (as taught in maths lessons when you're 6).  So, add brackets to make it explicit.  Assembly doesn't use brackets, so it shouldn't make the slightest bit of difference to the quality of the resultant code, but it might make all the difference to your calculations.

[Reply #7 on:]

Some of the order of precedences can be a little grey

I disagree. The precedence rules are quite well defined.

And can you remember the order of precedence of ALL the operators off the top of your head?

THIS is the real problem. I can't. I can remember that the order is left to right for operators of the same precedence, that multiplication and division are higher than addition and subtraction, that multiplication and division have the same precedence, and that addition and subtraction have the same precedence.

Where ==, >=, >, <=, <, comma, dot, ->, the various shift operators, and the other bit operators fit I have no clue, without looking them up.

But, I do know that parentheses let ME control the order the way I want. So, I use them.

I think OPs use of parentheses around the comparison (as in (digitalRead(n) == HIGH)) are a good idea. It clearly indicates, to me, that it is the result of that comparison that is being assigned to the variable.

[Reply #8 on:]

Definitely the first one is better as it is the most explicit.

Bob Martin (from the book Clean code) would say "use descriptive names where possible" and add spaces around the ==

boolean isButtonXPressed = (digitalRead(ButtonX) == HIGH);  

This makes the code self documenting

I go one step further with "descriptive names" and define

Code:

const boolean ButtonDown = false; // button connects to GND
...
if(digitalRead(pinButton) == ButtonDown){...}

If I need to change the button to high-side switching, there is only one line of code to change

[Reply #9 on:]

I go one step further with "descriptive names" and define

Code:

const boolean ButtonDown = false; // button connects to GND
...
if(digitalRead(pinButton) == ButtonDown){...}

If I need to change the button to high-side switching, there is only one line of code to change

Thats what enums are great for:

Code:

enum BUTTON_STATE{
  ButtonDown ,
  ButtonUp
};
...
if(digitalRead(pinButton) == ButtonDown){...}

[Reply #10 on:]

Code:

const boolean ButtonDown = false; // button connects to GND

I like the approach, but I'd argue that the type and value should match the return type and value of digitalRead():

Code:

const int ButtonDown = LOW; // button connects to GND

[Reply #11 on:]

Code:

const boolean ButtonDown = false; // button connects to GND

I like the approach, but I'd argue that the type and value should match the return type and value of digitalRead():

Code:

const int ButtonDown = LOW; // button connects to GND

... why is digitalRead() even an int?!  And on an 8 bit core too.  It really should be either (unsigned) char, or boolean.

"Arduino.  Helping to encourage bad practices since 2005."