Spurious brackets in C

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why does everyone, including Atmel, put brackets around C shift expressions such as:

 

TCCR0A = (3<<COM0A0) | (3<<COM0B0) | (3<<WGM00);

Unless I've misread it the C spec clearly states that the shift operators take priority over the bitwise logical operators, so it's only necessary, and clearer, to write:

 

TCCR0A = 3<<COM0A0 | 3<<COM0B0 | 3<<WGM00;

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnsondavies wrote:

... and clearer...

 

In general it's considered good practice to put brackets around sub-expressions to make clear your intent and to avoid the need to have to remember operator precedence.

 

In the example you gave it is perhaps not so important but if you are going to do it in other parts of your code then it makes sense, if only to be consistent, to do it everywhere.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnsondavies wrote:

Why does everyone, including Atmel, put brackets around C shift expressions such as:

 

TCCR0A = (3<<COM0A0) | (3<<COM0B0) | (3<<WGM00);

Unless I've misread it the C spec clearly states that the shift operators take priority over the bitwise logical operators, so it's only necessary, and clearer, to write:

 

TCCR0A = 3<<COM0A0 | 3<<COM0B0 | 3<<WGM00;

 

 

Yes,  you are quite correct about operator precedence.    Like Andy,   I am happier when there is no ambiguity.

The common occasions when you can come unstuck are when the expressions are more complex.  e.g.

 

TCCR0A |= 3<<COM0A0;

TCCR0A |= (3<<COM0A0);

TCCR0A &= ~3<<COM0A0;

TCCR0A &= ~(3<<COM0A0);

TCCR0A = 3<<2 + 1;

TCCR0A = (3<<(2 + 1));

 

The "Code Editor" seems to be completely broken this morning!

 

I 'know' which of those statements will do what I want.    I doubt if it is obvious to every reader.    There are some people who enjoy making something look obtuse or difficult.     For the sake of a little wear and tear on my fingers / keyboard,    I find the extra parentheses clearer.

 

The real mystery is why people avoid the <Space> key.    It is easier to hit than all the others.    The difference in clarity and readability is massive.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnsondavies wrote:
... clearer ...

Is a matter of great debate!

 

I'm with Brian on this: I would recommend the "unnecessary" brackets because

  1. It's a good habit - it means you're less likely to be caught out when you really should have had brackets!
     
  2. It makes the writer's intention clear.
     
  3. It's easier to maintain, because it's safer against modifications which might upset things - much like the use of "unnecessary" braces...

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnsondavies wrote:

Why does everyone, including Atmel, put brackets around C shift expressions such as:

 

TCCR0A = (3<<COM0A0) | (3<<COM0B0) | (3<<WGM00);

Unless I've misread it the C spec clearly states that the shift operators take priority over the bitwise logical operators, so it's only necessary, and clearer, to write:

 

TCCR0A = 3<<COM0A0 | 3<<COM0B0 | 3<<WGM00;

 

 

Yes,  you are quite correct about operator precedence.    Like Brian,   I am happier when there is no ambiguity.

The common occasions when you can come unstuck are when the expressions are more complex.  e.g.

 

TCCR0A |= 3<<COM0A0;

TCCR0A |= (3<<COM0A0);

TCCR0A &= ~3<<COM0A0;

TCCR0A &= ~(3<<COM0A0);

TCCR0A = 3<<2 + 1;

TCCR0A = (3<<(2 + 1));

 

The "Code Editor" seems to be completely broken this morning!

 

I 'know' which of those statements will do what I want.    I doubt if it is obvious to every reader.    There are some people who enjoy making something look obtuse or difficult.     For the sake of a little wear and tear on my fingers / keyboard,    I find the extra parentheses clearer.

 

The real mystery is why people avoid the <Space> key.    It is easier to hit than all the others.    The difference in clarity and readability is massive.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
 Like Andy,   I am happier when there is no ambiguity

Your post appeared before mine - how did you know what I was writing?!?!?!

 

surprise

 

Spooky!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The "Code Editor" seems to be completely broken this morning!

It's been broken for a while now - reported a week ago: https://www.avrfreaks.net/forum/c...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't.    It was only when I pressed the [Post] button that I saw it was Brian Fairchild who had written the previous reply.    So I made a swift edit!

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I made a swift edit!

Which has somehow turned into a double post!

 

Don't you just love this forum software...?!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your interesting replies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Besides, we got full-reel quantities of both left and right parenthesis from the distributor when they were on sale.  Buying them in quantity like that makes their use virtually free.

 

BTW, I've always used the "English grammar" names of parentheses, brackets, and braces as listed in the quote below.  Over decades of interacting with other programmers, that naming is certainly not universal as this thread shows.  So, are braces the squiggly things or do they hold your pants up?

 

Brackets, Braces and Parentheses

Brackets, braces and parentheses are symbols used to contain words that are a further explanation or are considered a group.

Parentheses ( () ) are curved notations used to contain further thoughts or qualifying remarks. However, parentheses can be replaced by commas without changing the meaning in most cases. For example: John and Jane ( who were actually half brother and sister ) both have red hair.

Brackets are the squared off notations ([]) used for technical explanations. YourDictionary uses them when you look up word definitions. At the bottom of each definition page, brackets surround a technical description of where the word originated.

Braces ({}) are used to contain two or more lines of text or listed items to show that they are considered as a unit. They are not commonplace in most writing, but can be seen in computer programming to show what should be contained within the same lines.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
I've always used the "English grammar" names of parentheses, brackets, and braces as listed in the quote below.  Over decades of interacting with other programmers, that naming is certainly not universal as this thread shows.

 

I think they are pretty universally accepted as the "Official" names; but people do also use them "colloquially" - particularly "brackets" as a generic term.

 

"Parentheses" and "Braces" are not ambiguous, but I would always say "square Brackets" for the avoidance of doubt when speaking specifically of '[' and ']'

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I find it easier to use the correct terms.     Otherwise curvy, square or curly or squiggly just confuse.

 

We all hold strong personal opinions about C layout and formatting.

The Compiler could not care how you do it.

 

Human beings do find some styles more attractive to read.    IMHO,    making your code readable is the first step in debugging.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Clear" is clearly in the eye of the beholder. For most of us, clear is what ever we grew up with. 

 

Much of my idea of clearness has been driven by maintaining my own code. It is a terrible shock to go back to code written only a few weeks ago, and not be able to decipher  how it is supposed to work., For me, David is spot-on! And, yes, that  space bar. I find that it  really improves readability. For example (for me)

if (x==y) ...

vs 

if ( x == y ) ...

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net