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;
... 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.
david.prentice 
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.
... clearer ...
Is a matter of great debate!
I'm with Brian on this: I would recommend the "unnecessary" brackets because
david.prentice 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.
Like Andy, I am happier when there is no ambiguity
Your post appeared before mine - how did you know what I was writing?!?!?!
Spooky!
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...
david.prentice 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.
I made a swift edit!
Which has somehow turned into a double post!
Don't you just love this forum software...?!
Thank you for your interesting replies.
theusch 
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.
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 ']'
david.prentice 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.
"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
