why no curly brackets in blink without delay ?

I have always used curley brackets around both if and else instructions, as per reference, but I have just noticed that there are none in the if/else part of the blink without delay example.

// if the LED is off turn it on and vice-versa:
if (ledState == LOW)
ledState = HIGH;
else
ledState = LOW;

Whats the difference / advantage?

You can resign the brackets if you only have one single instruction to be executed.

It doesn't have any advantages except saving two bracket charactes and in my opinion it's really bad coding style. It's a common cause of defect as you allways run the risk of adding another instruction to be executed in the if/else block but forget to add brackets. Also it makes the code harder to read.

Snippet1 + Snippet2 do the same thing:

// Snippet1
if (ledState == LOW)
  ledState = HIGH;

// Snippet2
if (ledState == LOW) {
  ledState = HIGH;
}

But if you add another instruction you have to add brackets. Snippet3 + Snippet4 are not doing the same thing.

// Snippet3
if (ledState == LOW)
  ledState = HIGH;
  ledState2 = HIGH;

// Snippet4
if (ledState == LOW) {
  ledState = HIGH;
  ledState2 = HIGH;
}
// if the LED is off turn it on and vice-versa:
    if (ledState == LOW)
      ledState = HIGH;
    else
      ledState = LOW;

akaledState = !ledState;

thank guys, that makes sense, and the ledState = !ledState; is so self explanatory I will stick to that in future.

[OT] One of my favourite "weeding-out" interview questions used to be
"I have a variable that can have the value three or five.
If the value is three, make it five, if it is five, make it three.
Your answer should not contain an "if".

I am a newbie remember, bu t is it something like x = 15/ x ???

That might work, but a divide is expensive.

I'll think about it when I have finished my rush job, it sounds like a " take away the number you first thought of" question :stuck_out_tongue:

Take away from the sum of the number you first thought of!

AWOL:
[OT] One of my favourite "weeding-out" interview questions used to be
"I have a variable that can have the value three or five.
If the value is three, make it five, if it is five, make it three.
Your answer should not contain an "if".

switch (var)
  {
  case 3: var = 5; break;
  case 5: var = 3; break;
  }

Seriously, just kidding. :wink:

var ^= 2;

(edit) In case you don't read page 2, it should be:

var ^= 6;

var ^= 2;

Well, thank you very much Mr Gammon, if you'd like to collect your expenses on your way out...
Next candidate, please.

See? Great question for sorting the wheat from the chaff.

Almost as good as the interviewee asked "What sort of range of numbers could you expect to store in an eight bit memory location?"
"Plus or minus 144" came back the answer.

Next.

Boffin1:
I have always used curley brackets around both if and else instructions, as per reference, but I have just noticed that there are none in the if/else part of the blink without delay example.

// if the LED is off turn it on and vice-versa:
if (ledState == LOW)
ledState = HIGH;
else
ledState = LOW;

Whats the difference / advantage?

Or replace with:

digitalWrite(ledPin, ! digitalRead (ledPin));

That does away with a variable which might not have the value you expect in it.

AWOL:
Well, thank you very much Mr Gammon, if you'd like to collect your expenses on your way out...

Hang on a tic, I have a better one:

byte states [6] = { 0, 1, 2, 5, 4, 3 };
var = var [states];

Do I pass?

OK so how does that work, and are Mr Gammon's expensive less than my dividing ?

The lookup table is interesting and feasible, if a little wasteful of RAM.
It will certainly be quicker than a method involving a division operation on a processor that doesn't have a divide instruction.

The XOR is going to be as quick as the subtract method, but only if the operands are correct :wink:

AWOL:

var ^= 2;

Well, thank you very much Mr Gammon, if you'd like to collect your expenses on your way out...

Oh wait, I should have said:

{
var ^= 2;
}

Just in case you want to put an "if" around it.

Boffin1:
OK so how does that work, and are Mr Gammon's expensive less than my dividing ?

Look at the bit patterns. Also a lot of microprocessors don't have a divide instruction, but almost certainly they have an XOR which is implemented very quickly.

Dividing will be implemented in software, XOR in hardware.

Oh wait, I should have said:

Code:

{
var ^= 2;

No you should have said:

var ^= 6;

or var = 8 - var;

AWOL:
Take away from the sum of the number you first thought of!

...

The XOR is going to be as quick as the subtract method, but only if the operands are correct :wink:

Faster. An add and a subtract will be slower than a single XOR.

var ^= 6;

True, I got my facts wrong. That will teach me not to test. I knew it was something to do with bits and stuff.

Look on the bright side. In 24 hours there will be 30 different ways of answering the question posted. And a few flame wars as well. :stuck_out_tongue: