Go Down

Topic: Interchanging HIGH/LOW with true/false (Read 1 time) previous topic - next topic

stoopkid

I notice that both of these lines work:

Code: [Select]

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

UKHeliBob

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.
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

PaulS

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.

robtillaart

#3
Feb 21, 2013, 09:23 am Last Edit: Feb 21, 2013, 10:36 am by robtillaart Reason: 1
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
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Nick Gammon

Quote

Code: [Select]

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



You don't need the brackets, so:

Code: [Select]

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: [Select]

boolean pressed = digitalRead(3) == LOW;


Second, semantically, it is "true" you did a digital read, but did it return HIGH or LOW?
http://www.gammon.com.au/electronics

michinyon

Some people advocate writing code like   
Code: [Select]

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.

majenko


Some people advocate writing code like   
Code: [Select]

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.
Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

PaulS

Quote
Some of the order of precedences can be a little grey

I disagree. The precedence rules are quite well defined.

Quote
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.

olf2012


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: [Select]
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

pYro_65


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

Code: [Select]
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: [Select]
enum BUTTON_STATE{
 ButtonDown ,
 ButtonUp
};
...
if(digitalRead(pinButton) == ButtonDown){...}

PeterH

Code: [Select]
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: [Select]
const int ButtonDown = LOW; // button connects to GND
I only provide help via the forum - please do not contact me for private consultancy.

majenko


Code: [Select]
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: [Select]
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."
Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Go Up
 

Quick Reply

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.
Name:
Email:

shortcuts: alt+s submit/post or alt+p preview