On 19/04/2022 19:40, Kaz Kylheku wrote:
> On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
>> On 18/04/2022 18:38, Kaz Kylheku wrote:
>>> On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 15/04/2022 20:25, Ben wrote:
>>>>> Guillaume <message@bottle.org> writes:
>>>>>
>>>>>> Le 11/04/2022 à 22:27, Ben a écrit :
>>>>>>> I shall have to remain in the dark then about what you consider a good
>>>>>>> start because the quote "Limited dependence should be placed on operator
>>>>>>> precedence rules in expressions" I think MISRA costs money.
>>>>>>
>>>>>> If you use MISRA in a professional context, you should of course buy a
>>>>>> copy, but if you're just curious or it's for your own personal use,
>>>>>> then it's easy to get ahold of a copy.
>>>>>>
>>>>>> But I explicitely mentioned the rule number that applied here, and
>>>>>> with this number, you'll find the details online very easily without
>>>>>> needing to get the whole document.
>>>>>
>>>>> I didn't succeed. Only spent a few minutes but all I could find is
>>>>> people quoting some (or many all of) that rule in compliance statements.
>>>>>
>>>>> One says:
>>>>>
>>>>> "MISRA C:2012 Rule 12.1: The precedence of operators within
>>>>> expressions should be made explicit"
>>>>>
>>>>> but that can't be the whole rule and, as quoted, it sounds very odd.
>>>>>
>>>>
>>>> It is not the whole rule, which is fleshed out more and has a number of
>>>> examples. It is also an "advisory" rule, rather than a "required" rule,
>>>> and it contains the rationale note:
>>>>
>>>> """
>>>> It is recognized that overuse of parentheses can clutter the code and
>>>> reduce its readability. This rule aims to achieve a compromise between
>>>> code that is hard to understand because it contains either too many or
>>>> too few parentheses.
>>>> """
>>>>
>>>> Whether or not you think it succeeds in this aim is, clearly, a matter
>>>> of opinion!
>>>>
>>>> An example of a non-compliant expression is :
>>>>
>>>> x = a == b ? a : a - b;
>>>>
>>>> with the compliant version being :
>>>>
>>>> x = ( a == b ) ? a : ( a - b );
>>>
>>> This is actually a really poor example.
>>>
>>> What if I don't remember whether = has a lower precedence than ?:
>>
>> You have to require /some/ knowledge of C. Assignments are the lowest
>> precedence (other than the comma operator, which MISRA bans or at least
>> strongly discourages anyway). Similarly, MISRA expects you to
>> understand that the unary operators have higher precedence.
>>
>>>
>>> If your answer is that it obviously does, then we can easily
>>> argue that, likewise, == and - "obviously" have a higher precedence, and
>>> so nothing needs parenthesizing.
>>>
>>> Rather, if I were only allowed to insert one set of parentheses, I would
>>> prioritize the insertion of this pair:
>>>
>>> x = (a == b ? a : a - b)
>>>
>>> Then if additional parens were still needed:
>>>
>>> x = ((a == b) ? (a) : (a - b))
>>>
>>> The inner one is for consistency: a is parallel with a - b.
>>> This is analogous to bracing both branches of if/else if one
>>> branch is braced.
>>>
>>
>> To me, this is not so much a matter of remembering the precedence rules
>> as being able to tell at a glance what the expression means - and making
>> it as difficult as possible for (almost) anyone to misinterpret it when
>> reading it, even if they have different habits for spacing or
>> parenthesising.
>>
>> I believe it is highly unlikely for "x=a + b;" to be misinterpreted,
>> thus adding parenthesis is unhelpful. But "x=a == b?a:a-b;" could
>> certainly lead to confusion, or at least longer parse times - putting
>> parenthesis as suggested by MISRA would help, putting them where you
>> suggested would not.
>
> Sure, OK. But then, what is the point of the "x = " in the MISRA
> example?
>
> x = ( a == b ) ? a : ( a - b );
>
> The possibility remains that this be misread as:
>
> (x = ( a == b )) ? a : ( a - b );
>
> Why is the assignment included in this example; if its apparent
> ambiguity isn't being taken care of?

As I said - /some/ knowledge of C is taken as given. The details of the
rule specifically talk about operators of precedence higher than
assignment - the reader is expected to understand that assignment is the
lowest precedence (MISRA bans the comma operator).

(I'm not saying this is necessarily a perfect choice - merely that it is
the choice MISRA made.)

>
> What it is that the reader is supposed to be confused by if we remove
> the left pair of parentheses.
>
> x = a == b ? a : ( a - b );
>
> Are the parentheses supposed to rule out this misparse?
>
> x = a == (b ? a : ( a - b )).
>
> If so, that can be demonstrated without the x = because it's
> an internal matter within just ternary expression.
>
> Or is it this misparse:
>
> (x = a) == b ? a : ( a - b ).

I did not write MISRA - I quoted from it. There are endless ways to
misinterpret things, intentionally and unintentionally, whether it be
statements or expressions in C, or rules in a coding standard.

>
> But that is an issue between just the = and == operator that
> can be put into a simpler recommendation, like
>
> "parenthesize equality/inequality expressions that are next to
> assignment operators. Don't write:
>
> flag = foo == bar
>
> but
>
> flag = (foo == bar)
>
> or
>
> row += i % 10 == 0
>
> but rather
>
> row += (i % 10 == 0)"

I'd agree that these are good rules.

>
> The thing is that x = y ? z : w is actually a famous ambiguity,
> which revolves around the precedence of = versus ?:.
> Someone who thinks = is higher misreads it as (x = y) ? z : w.
> This can be a valid interpretation of z and w have side effects.
>

MISRA already bans the use of the result of the assignment operator.
(Some people will disagree with that one, others will agree - it is not
without reason that many programming languages have assignment as a
statement, not an expression.)

> Parenthesizing y does nothing: x = (y) ? z : w.
>
> You need: x = (y ? z : w). Aha, only y is tested, and then
> x receives either z or w.
>

I think you could reasonably argue that "x = (y ? z : w);" is clearer
than without the parentheses. But for the original expression, I'd want
parentheses as MISRA had them: "x = (a == b) ? a : (a - b);". I think
an extra set of parentheses around the whole assigned expression would
add clutter rather than clarity.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

[...]

> This reminds be a discussion [...] about
> MISRA Rule 34 (required):
> "The operands of a logical && or || shall be primary expressions
> if the operands contain binary operators."
>
> I pointed out that this rule mandates that at least one pair of
> parentheses be inserted in the following expression:
>
> (a && b) && c
>
> because '&&' is a binary operator, and a && b is the left operand
> of the second && operator.
>
> I also pointed out that, "the operands contain" could either be
> interpreted as meaning "both operands contain", which would allow
> a + b && c, or "either operand contains", which would require
> (a+b) && (c).

The stated rule -- under the "either" interpretation -- requires
(a+b) && c, not (a+b) && (c).

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Recently, I wrote:
>
> board & 1 << row * COLS + col
>
> . Not knowing the precedence of operators by heart,
> I planned to look up the precedence rules and then insert
> any necessary parentheses. But then, I had this thought:
> "C was made for such expression; just trust the language.".

In conjunction with the other thread on operator precedence, I am
interested to ask about what people know without having to look
it up. So my question is, which operators, or precedence levels,
do you feel confident that you can say correctly how C parses
expressions that have those operators? (Feel free to indicate
partial understanding in some cases if that is applicable.)

Note that "precedence" here is meant as a stand-in for more general
parsing relationships, such as associativity, asymmetry, etc.

On Monday, April 25, 2022 at 11:40:47 AM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
>
> [...]
>
> > This reminds be a discussion [...] about
> > MISRA Rule 34 (required):
> > "The operands of a logical && or || shall be primary expressions
> > if the operands contain binary operators."
....
> > I also pointed out that, "the operands contain" could either be
> > interpreted as meaning "both operands contain", which would allow
> > a + b && c, or "either operand contains", which would require
> > (a+b) && (c).
> The stated rule -- under the "either" interpretation -- requires
> (a+b) && c, not (a+b) && (c).

Sorry - to make my point properly, I should have used a right operand
which was not, itself, a primary-expression. Under the second
interpretation, that rule requires that
a + b && c[5]

be written as

(a+b) && (c[5])

Guillaume <message@bottle.org> writes:

> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>
>> Recently, I wrote:
>>
>> board & 1 << row * COLS + col
>
> If I saw this coming from someone in my team, I would probably fire them. =)
>
> I'm not even sure this is correct from what you really intended. But
> even if it is, there's a rule in programming, IMO, that's above the
> programming language's grammar: readability for us humans.
>
> Code we write is meant for humans, not machines. That's something
> people forget way too often. That's why we write using higher-level
> languages, not assembly or even machine code. Or, look at the
> obfuscated C contest and such. This is proper C from a language
> standpoint, but nothing you'd want to deal with.
>
> The readability rule that applies here is, if you need more than a few
> seconds figuring out what a given statement exactly does, and may have
> to even open the C standard to make sure, then it's badly
> written. Rewrite it.

Human readability can be improved as follows:

board & 1 << row*COLS+col

On 25/04/2022 20:10, Tim Rentsch wrote:
> Guillaume <message@bottle.org> writes:
>
>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>
>>> Recently, I wrote:
>>>
>>> board & 1 << row * COLS + col
>>
>> If I saw this coming from someone in my team, I would probably fire them. =)
>>
>> I'm not even sure this is correct from what you really intended. But
>> even if it is, there's a rule in programming, IMO, that's above the
>> programming language's grammar: readability for us humans.
>>
>> Code we write is meant for humans, not machines. That's something
>> people forget way too often. That's why we write using higher-level
>> languages, not assembly or even machine code. Or, look at the
>> obfuscated C contest and such. This is proper C from a language
>> standpoint, but nothing you'd want to deal with.
>>
>> The readability rule that applies here is, if you need more than a few
>> seconds figuring out what a given statement exactly does, and may have
>> to even open the C standard to make sure, then it's badly
>> written. Rewrite it.
>
> Human readability can be improved as follows:
>
> board & 1 << row*COLS+col
>

If I saw that coming from someone in my team, I would treat it as worse
than the original. Anyone who thinks mixing inconsistent spacing into
this improves things, has completely missed the point (unless they are
using some programming language that considers the number of spaces in
an expression as significant).

For code clarity, it is important that the compiler and human readers
agree on what the code means, that the human can easily see what it
means, and easily see that the compiler will view it the same way.
Changing the spacing does not improve things if the compiler and the
human had different ideas of what the code meant - all it does is make
it marginally clearer to readers what the writer thinks it means, at the
expense of making it harder to see any possible errors.

If you think the first expression was clear enough, that's a reasonable
position - others disagree, but it can depend on the kind of programming
and the kind of programmers involved. But IMHO if the first expression
is not considered clear enough for the needs of the programming task in
hand, then the second version is worse.

(I don't expect Tim to read this, and certainly not to reply to it, as I
am on his naughty list - but others may read it.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Guillaume <message@bottle.org> writes:
>
>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>
>>> Recently, I wrote:
>>>
>>> board & 1 << row * COLS + col
>>
>> If I saw this coming from someone in my team, I would probably fire them. =)
>>
>> I'm not even sure this is correct from what you really intended. But
>> even if it is, there's a rule in programming, IMO, that's above the
>> programming language's grammar: readability for us humans.
>>
>> Code we write is meant for humans, not machines. That's something
>> people forget way too often. That's why we write using higher-level
>> languages, not assembly or even machine code. Or, look at the
>> obfuscated C contest and such. This is proper C from a language
>> standpoint, but nothing you'd want to deal with.
>>
>> The readability rule that applies here is, if you need more than a few
>> seconds figuring out what a given statement exactly does, and may have
>> to even open the C standard to make sure, then it's badly
>> written. Rewrite it.
>
>Human readability can be improved as follows:
>
> board & 1 << row*COLS+col

Or,

inline _Bool
test_bit(uint64_t qword, size_t bitnum)
{ return (_Bool) (qword & (1ul << bitnum)) != 0;
}

if (test_bit(board, row*COLS+col)) {
...
}

Easily extended to support an array of uint64_t
when ROWS*COLS > sizeof(uint64_t) * BITS_PER_BYTE.

David Brown <david.brown@hesbynett.no> writes:

> On 25/04/2022 20:10, Tim Rentsch wrote:
>> Guillaume <message@bottle.org> writes:
>>
>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>
>>>> Recently, I wrote:
>>>>
>>>> board & 1 << row * COLS + col
>>>
>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>
>>> I'm not even sure this is correct from what you really intended. But
>>> even if it is, there's a rule in programming, IMO, that's above the
>>> programming language's grammar: readability for us humans.
>>>
>>> Code we write is meant for humans, not machines. That's something
>>> people forget way too often. That's why we write using higher-level
>>> languages, not assembly or even machine code. Or, look at the
>>> obfuscated C contest and such. This is proper C from a language
>>> standpoint, but nothing you'd want to deal with.
>>>
>>> The readability rule that applies here is, if you need more than a few
>>> seconds figuring out what a given statement exactly does, and may have
>>> to even open the C standard to make sure, then it's badly
>>> written. Rewrite it.
>>
>> Human readability can be improved as follows:
>>
>> board & 1 << row*COLS+col
>
> If I saw that coming from someone in my team, I would treat it as worse
> than the original. Anyone who thinks mixing inconsistent spacing into
> this improves things, has completely missed the point (unless they are
> using some programming language that considers the number of spaces in
> an expression as significant).

You presumably think that there is only one notion of consistent
spacing, but spacing to show operator binding is consistent
with... well, with doing so. I've seen it quite a lot. I do it myself
even when it hardly matters:

int mid = (low + high)/2;

looks better, to me, with the /2 glued right up to the ()s.

> For code clarity, it is important that the compiler and human readers
> agree on what the code means, that the human can easily see what it
> means, and easily see that the compiler will view it the same way.

The trouble with these sort of overly general platitudes is they don't
help people like me (now thankfully out of the game) to know what you
think needs to be clarified. How would you parenthesise the above, and
why?

<cut>
--
Ben.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>Guillaume <message@bottle.org> writes:
>>
>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>
>>>> Recently, I wrote:
>>>>
>>>> board & 1 << row * COLS + col
>>>
>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>
>>> I'm not even sure this is correct from what you really intended. But
>>> even if it is, there's a rule in programming, IMO, that's above the
>>> programming language's grammar: readability for us humans.
>>>
>>> Code we write is meant for humans, not machines. That's something
>>> people forget way too often. That's why we write using higher-level
>>> languages, not assembly or even machine code. Or, look at the
>>> obfuscated C contest and such. This is proper C from a language
>>> standpoint, but nothing you'd want to deal with.
>>>
>>> The readability rule that applies here is, if you need more than a few
>>> seconds figuring out what a given statement exactly does, and may have
>>> to even open the C standard to make sure, then it's badly
>>> written. Rewrite it.
>>
>>Human readability can be improved as follows:
>>
>> board & 1 << row*COLS+col
>
>
> Or,
>
> inline _Bool
> test_bit(uint64_t qword, size_t bitnum)
> {
> return (_Bool) (qword & (1ul << bitnum)) != 0;
> }

But this makes me wonder why uint64_t and not uint_least64_t. Do you
really need no more than 64 bits? And why 1ul rather than UINT64_C(1)
(or (uint64_t)1)?

And what is going on with the cast, the != and the return value
conversion? Why does an integer value have to explicitly cast to _Bool
before testing for non-zero, but the integer result (albeit now 0 or 1)
can be implicitly converted to the _Bool return type? This would make
me cautious about other code, especially if I were porting to some new C
compiler. It looks like code that's been copied and edited.

> if (test_bit(board, row*COLS+col)) {

I'd rather bit_is_set(...) since test_bit is agnostic about which way
the test goes. In the case of bits I know one is almost always testing
for set and not clear, but I like to stick to this habit.

> ...
> }
>
> Easily extended to support an array of uint64_t
> when ROWS*COLS > sizeof(uint64_t) * BITS_PER_BYTE.

s/BITS_PER_BYTE/CHAR_BIT/?

--
Ben.

Ben <ben.usenet@bsb.me.uk> writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Guillaume <message@bottle.org> writes:
>>>
>>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>>
>>>>> Recently, I wrote:
>>>>>
>>>>> board & 1 << row * COLS + col
>>>>
>>>> If I saw this coming from someone in my team, I would probably
>>>> fire them. =)
>>>>
>>>> I'm not even sure this is correct from what you really intended.
>>>> But even if it is, there's a rule in programming, IMO, that's
>>>> above the programming language's grammar: readability for us
>>>> humans.
>>>>
>>>> Code we write is meant for humans, not machines. That's something
>>>> people forget way too often. That's why we write using higher-level
>>>> languages, not assembly or even machine code. Or, look at the
>>>> obfuscated C contest and such. This is proper C from a language
>>>> standpoint, but nothing you'd want to deal with.
>>>>
>>>> The readability rule that applies here is, if you need more than
>>>> a few seconds figuring out what a given statement exactly does,
>>>> and may have to even open the C standard to make sure, then it's
>>>> badly written. Rewrite it.
>>>
>>> Human readability can be improved as follows:
>>>
>>> board & 1 << row*COLS+col
>>
>> Or,
>>
>> inline _Bool
>> test_bit(uint64_t qword, size_t bitnum)
>> {
>> return (_Bool) (qword & (1ul << bitnum)) != 0;
>> }
>
> But this makes me wonder why uint64_t and not uint_least64_t. Do
> you really need no more than 64 bits? And why 1ul rather than
> UINT64_C(1) (or (uint64_t)1)?
>
> And what is going on with the cast, the != and the return value
> conversion? Why does an integer value have to explicitly cast to
> _Bool before testing for non-zero, but the integer result (albeit
> now 0 or 1) can be implicitly converted to the _Bool return type?
> This would make me cautious about other code, especially if I were
> porting to some new C compiler. It looks like code that's been
> copied and edited.
>
>> if (test_bit(board, row*COLS+col)) {
>
> I'd rather bit_is_set(...) since test_bit is agnostic about which
> way the test goes. In the case of bits I know one is almost always
> testing for set and not clear, but I like to stick to this habit.

Your comments cover most of what I was going to say. To add one
more thought, the function definition can be simplified:

inline _Bool
bit_is_set( uintmax_t bits, unsigned n ){
return bits>>n & 1;
}

This definition is for me easier to take in and understand than
how test_bit() is defined. Of course other people may have other
impressions.

On 25/04/2022 22:18, Ben wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 25/04/2022 20:10, Tim Rentsch wrote:
>>> Guillaume <message@bottle.org> writes:
>>>
>>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>>
>>>>> Recently, I wrote:
>>>>>
>>>>> board & 1 << row * COLS + col
>>>>
>>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>>
>>>> I'm not even sure this is correct from what you really intended. But
>>>> even if it is, there's a rule in programming, IMO, that's above the
>>>> programming language's grammar: readability for us humans.
>>>>
>>>> Code we write is meant for humans, not machines. That's something
>>>> people forget way too often. That's why we write using higher-level
>>>> languages, not assembly or even machine code. Or, look at the
>>>> obfuscated C contest and such. This is proper C from a language
>>>> standpoint, but nothing you'd want to deal with.
>>>>
>>>> The readability rule that applies here is, if you need more than a few
>>>> seconds figuring out what a given statement exactly does, and may have
>>>> to even open the C standard to make sure, then it's badly
>>>> written. Rewrite it.
>>>
>>> Human readability can be improved as follows:
>>>
>>> board & 1 << row*COLS+col
>>
>> If I saw that coming from someone in my team, I would treat it as worse
>> than the original. Anyone who thinks mixing inconsistent spacing into
>> this improves things, has completely missed the point (unless they are
>> using some programming language that considers the number of spaces in
>> an expression as significant).
>
> You presumably think that there is only one notion of consistent
> spacing, but spacing to show operator binding is consistent
> with... well, with doing so. I've seen it quite a lot. I do it myself
> even when it hardly matters:
>
> int mid = (low + high)/2;
>
> looks better, to me, with the /2 glued right up to the ()s.

I tend to stick to consistent spacing, but I am always open to bending
such rules if it results in clearer code. (And I also understand that
different people have different spacing rules that they apply at least
reasonably consistently.)

But I think it is rare that unusual, inconsistent or extra spaces are
going to make an expression significantly clearer or easier to parse
(for the human reader). You might feel that skipping the spaces on your
"/2" example makes the line look nicer - and maybe it does, perhaps
depending on fonts and other visual details. However, I don't think
you'd claim that it makes the functional effect of the statement more
immediately obvious to the reader, or reduces the risk of it being
misinterpreted.

>
>> For code clarity, it is important that the compiler and human readers
>> agree on what the code means, that the human can easily see what it
>> means, and easily see that the compiler will view it the same way.
>
> The trouble with these sort of overly general platitudes is they don't
> help people like me (now thankfully out of the game) to know what you
> think needs to be clarified. How would you parenthesise the above, and
> why?
>

I have intentionally been a bit vague on the details, because I don't
think there is one correct set of rules that apply to all people, all
projects, all types of coding task.

I would prefer :

board & 1 << (rows * COLS + col)

I am not sure I would go as far as MISRA would like :

board & (1 << (rows * COLS + col))

There's no single one "correct" or "best" way to write this or any other
code. Maybe it would be better to have new "index" or "mask" variables
for part of the expression, if these were re-used in other code. Maybe
it should be refactored into a function.

Specific rule sets can be useful for specific purposes. MISRA was
developed for safety-critical automotive software. It would not be
suitable for Linux kernel programming. The Linux kernel coding standard
would not be useful for game programming. And so on.

But I think it /is/ possible to form general rules that apply across a
range of uses, and even a range of languages. That includes the
importance of coding for human readability, or avoiding undefined
behaviour (and making reliance on uncommon implementation-dependent
behaviour clear in the code - preferably via static assertions or
pre-processor checks).

David Brown <david.brown@hesbynett.no> writes:

> On 25/04/2022 22:18, Ben wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 25/04/2022 20:10, Tim Rentsch wrote:
>>>> Guillaume <message@bottle.org> writes:
>>>>
>>>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>>>
>>>>>> Recently, I wrote:
>>>>>>
>>>>>> board & 1 << row * COLS + col
>>>>>
>>>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>>>
>>>>> I'm not even sure this is correct from what you really intended. But
>>>>> even if it is, there's a rule in programming, IMO, that's above the
>>>>> programming language's grammar: readability for us humans.
>>>>>
>>>>> Code we write is meant for humans, not machines. That's something
>>>>> people forget way too often. That's why we write using higher-level
>>>>> languages, not assembly or even machine code. Or, look at the
>>>>> obfuscated C contest and such. This is proper C from a language
>>>>> standpoint, but nothing you'd want to deal with.
>>>>>
>>>>> The readability rule that applies here is, if you need more than a few
>>>>> seconds figuring out what a given statement exactly does, and may have
>>>>> to even open the C standard to make sure, then it's badly
>>>>> written. Rewrite it.
>>>>
>>>> Human readability can be improved as follows:
>>>>
>>>> board & 1 << row*COLS+col
>>>
>>> If I saw that coming from someone in my team, I would treat it as worse
>>> than the original. Anyone who thinks mixing inconsistent spacing into
>>> this improves things, has completely missed the point (unless they are
>>> using some programming language that considers the number of spaces in
>>> an expression as significant).
>> You presumably think that there is only one notion of consistent
>> spacing, but spacing to show operator binding is consistent
>> with... well, with doing so. I've seen it quite a lot. I do it myself
>> even when it hardly matters:
>> int mid = (low + high)/2;
>> looks better, to me, with the /2 glued right up to the ()s.
>
> I tend to stick to consistent spacing, but I am always open to bending
> such rules if it results in clearer code. (And I also understand that
> different people have different spacing rules that they apply at least
> reasonably consistently.)

I think mean you prefer the a fixed number of spaces (one) around each
binary operator and, guessing, none between unary operators and
operands.

> But I think it is rare that unusual, inconsistent or extra spaces are
> going to make an expression significantly clearer or easier to parse
> (for the human reader). You might feel that skipping the spaces on
> your "/2" example makes the line look nicer - and maybe it does,
> perhaps depending on fonts and other visual details. However, I don't
> think you'd claim that it makes the functional effect of the statement
> more immediately obvious to the reader, or reduces the risk of it
> being misinterpreted.

Indeed I would not. As you know, I am not that interested in surface
syntax. I have preferences, but can't get as het up about it as some
people seem to.

>>> For code clarity, it is important that the compiler and human readers
>>> agree on what the code means, that the human can easily see what it
>>> means, and easily see that the compiler will view it the same way.
>> The trouble with these sort of overly general platitudes is they don't
>> help people like me (now thankfully out of the game) to know what you
>> think needs to be clarified. How would you parenthesise the above, and
>> why?
>
> I have intentionally been a bit vague on the details, because I don't
> think there is one correct set of rules that apply to all people, all
> projects, all types of coding task.
>
> I would prefer :
>
> board & 1 << (rows * COLS + col)

Ta. That tells me what priorities you think people may confuse. If I
had to add a pair, I'd have gone with

board & (1 << rows * COLS + col)

since I would assume that a lot of C programmers know some C++ and
therefore know that one never has to parenthesise basic arithmetic in
C++ output expressions.

> I am not sure I would go as far as MISRA would like :
>
> board & (1 << (rows * COLS + col))

They leave it vague. Applying the rule strictly, it would require

board & (1 << ((rows * COLS) + col))

> There's no single one "correct" or "best" way to write this or any
> other code.

I know. I just like to see what other people prefer.

--
Ben.

On 26/04/2022 16:58, Ben wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 25/04/2022 22:18, Ben wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 25/04/2022 20:10, Tim Rentsch wrote:
>>>>> Guillaume <message@bottle.org> writes:
>>>>>
>>>>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>>>>
>>>>>>> Recently, I wrote:
>>>>>>>
>>>>>>> board & 1 << row * COLS + col
>>>>>>
>>>>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>>>>
>>>>>> I'm not even sure this is correct from what you really intended. But
>>>>>> even if it is, there's a rule in programming, IMO, that's above the
>>>>>> programming language's grammar: readability for us humans.
>>>>>>
>>>>>> Code we write is meant for humans, not machines. That's something
>>>>>> people forget way too often. That's why we write using higher-level
>>>>>> languages, not assembly or even machine code. Or, look at the
>>>>>> obfuscated C contest and such. This is proper C from a language
>>>>>> standpoint, but nothing you'd want to deal with.
>>>>>>
>>>>>> The readability rule that applies here is, if you need more than a few
>>>>>> seconds figuring out what a given statement exactly does, and may have
>>>>>> to even open the C standard to make sure, then it's badly
>>>>>> written. Rewrite it.
>>>>>
>>>>> Human readability can be improved as follows:
>>>>>
>>>>> board & 1 << row*COLS+col
>>>>
>>>> If I saw that coming from someone in my team, I would treat it as worse
>>>> than the original. Anyone who thinks mixing inconsistent spacing into
>>>> this improves things, has completely missed the point (unless they are
>>>> using some programming language that considers the number of spaces in
>>>> an expression as significant).
>>> You presumably think that there is only one notion of consistent
>>> spacing, but spacing to show operator binding is consistent
>>> with... well, with doing so. I've seen it quite a lot. I do it myself
>>> even when it hardly matters:
>>> int mid = (low + high)/2;
>>> looks better, to me, with the /2 glued right up to the ()s.
>>
>> I tend to stick to consistent spacing, but I am always open to bending
>> such rules if it results in clearer code. (And I also understand that
>> different people have different spacing rules that they apply at least
>> reasonably consistently.)
>
> I think mean you prefer the a fixed number of spaces (one) around each
> binary operator and, guessing, none between unary operators and
> operands.
>

Yes, on the whole.

>> But I think it is rare that unusual, inconsistent or extra spaces are
>> going to make an expression significantly clearer or easier to parse
>> (for the human reader). You might feel that skipping the spaces on
>> your "/2" example makes the line look nicer - and maybe it does,
>> perhaps depending on fonts and other visual details. However, I don't
>> think you'd claim that it makes the functional effect of the statement
>> more immediately obvious to the reader, or reduces the risk of it
>> being misinterpreted.
>
> Indeed I would not. As you know, I am not that interested in surface
> syntax. I have preferences, but can't get as het up about it as some
> people seem to.

I try not to get worked up about it, but I don't think I am as patient
and understanding as you!

>
>>>> For code clarity, it is important that the compiler and human readers
>>>> agree on what the code means, that the human can easily see what it
>>>> means, and easily see that the compiler will view it the same way.
>>> The trouble with these sort of overly general platitudes is they don't
>>> help people like me (now thankfully out of the game) to know what you
>>> think needs to be clarified. How would you parenthesise the above, and
>>> why?
>>
>> I have intentionally been a bit vague on the details, because I don't
>> think there is one correct set of rules that apply to all people, all
>> projects, all types of coding task.
>>
>> I would prefer :
>>
>> board & 1 << (rows * COLS + col)
>
> Ta. That tells me what priorities you think people may confuse. If I
> had to add a pair, I'd have gone with
>
> board & (1 << rows * COLS + col)
>
> since I would assume that a lot of C programmers know some C++ and
> therefore know that one never has to parenthesise basic arithmetic in
> C++ output expressions.

That's a reasonable point. A lot of people in my line of programming
come from the other direction - electronics, then assembly, then C, then
perhaps C++ for the "advanced" programmers. (I personally have jumped
around a great deal, and have not followed any logical progression.) It
is probably more common than it used to be for people to have worked
with C++ before moving into C programming on microcontrollers, though
often now they stick with C++ even on small devices.

>
>> I am not sure I would go as far as MISRA would like :
>>
>> board & (1 << (rows * COLS + col))
>
> They leave it vague. Applying the rule strictly, it would require
>
> board & (1 << ((rows * COLS) + col))

Yes, that would be the most strict application of the rules - but it is
common practice to accept that multiplication binds more tightly than
addition. (People vary in their programming backgrounds and
experiences, but we've all covered basic arithmetic conventions at school.)

>
>> There's no single one "correct" or "best" way to write this or any
>> other code.
>
> I know. I just like to see what other people prefer.
>

Yes. And I thought it was interesting to see your alternative
parenthesising.

On Tuesday, 26 April 2022 at 15:58:41 UTC+1, Ben wrote:
> David Brown writes:

> > board & 1 << (rows * COLS + col)
> Ta. That tells me what priorities you think people may confuse. If I
> had to add a pair, I'd have gone with
>
> board & (1 << rows * COLS + col)
>
> since I would assume that a lot of C programmers know some C++ and
> therefore know that one never has to parenthesise basic arithmetic in
> C++ output expressions.

<< isn't basic arithmetic.

> > I am not sure I would go as far as MISRA would like :
> >
> > board & (1 << (rows * COLS + col))
> They leave it vague. Applying the rule strictly, it would require
>
> board & (1 << ((rows * COLS) + col))

The relative precedences of * and + are fairly universal so this is going too far.

But I'd have to go and look up those for & and <<. Parentheses would be a good idea especially for fragments of code that might end up being ported across languages, or posted as 'pseudo-code'.

bart c <bart4858@gmail.com> writes:

> On Tuesday, 26 April 2022 at 15:58:41 UTC+1, Ben wrote:
>> David Brown writes:
>
>> > board & 1 << (rows * COLS + col)
>> Ta. That tells me what priorities you think people may confuse. If I
>> had to add a pair, I'd have gone with
>>
>> board & (1 << rows * COLS + col)
>>
>> since I would assume that a lot of C programmers know some C++ and
>> therefore know that one never has to parenthesise basic arithmetic in
>> C++ output expressions.
>
> << isn't basic arithmetic.

Yes, that's was my point.

--
Ben.

On 26/04/2022 20:19, David Brown wrote:
> Yes, that would be the most strict application of the rules - but it is
> common practice to accept that multiplication binds more tightly than
> addition. (People vary in their programming backgrounds and
> experiences, but we've all covered basic arithmetic conventions at school.)

Is this basic arithmetic:

int result = 8 / 2 * (2 + 2);

You'll be amazed to find that even top notch mathematicians will tell
you that the result of this statement is ambiguous. Order of evaluation
is very important here.

On Tuesday, 26 April 2022 at 16:31:11 UTC+3, David Brown wrote:
> On 25/04/2022 22:18, Ben wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >
> >> For code clarity, it is important that the compiler and human readers
> >> agree on what the code means, that the human can easily see what it
> >> means, and easily see that the compiler will view it the same way.
> >
> > The trouble with these sort of overly general platitudes is they don't
> > help people like me (now thankfully out of the game) to know what you
> > think needs to be clarified. How would you parenthesise the above, and
> > why?
> >
> I have intentionally been a bit vague on the details, because I don't
> think there is one correct set of rules that apply to all people, all
> projects, all types of coding task.
>
> I would prefer :
>
> board & 1 << (rows * COLS + col)
>
> I am not sure I would go as far as MISRA would like :
>
> board & (1 << (rows * COLS + col))
>
> There's no single one "correct" or "best" way to write this or any other
> code. Maybe it would be better to have new "index" or "mask" variables
> for part of the expression, if these were re-used in other code. Maybe
> it should be refactored into a function.
>
> Specific rule sets can be useful for specific purposes. MISRA was
> developed for safety-critical automotive software. It would not be
> suitable for Linux kernel programming. The Linux kernel coding standard
> would not be useful for game programming. And so on.
>
> But I think it /is/ possible to form general rules that apply across a
> range of uses, and even a range of languages. That includes the
> importance of coding for human readability, or avoiding undefined
> behaviour (and making reliance on uncommon implementation-dependent
> behaviour clear in the code - preferably via static assertions or
> pre-processor checks).

I have used simple rule that whatever static style analysis / code
formatting tool settings are accepted by team have to be followed.
Best is to integrate auto-formatting tool (like Clang-Format) into
build system and done.

If formatting is a build step and they still somehow manage
to push different parentheses, brackets, indentation or whitespace
into repo then that indicates that they did not even build what they
wrote.

But if no one can find a tool that enforces it then it is probably too
complicated style rule for to explain to humans as well and will
cause time wasted into bike-shedding if it was violated or wasn't.

On 27/04/2022 03:15, Sams Lara wrote:
> On 26/04/2022 20:19, David Brown wrote:
>> Yes, that would be the most strict application of the rules - but it is
>> common practice to accept that multiplication binds more tightly than
>> addition.  (People vary in their programming backgrounds and
>> experiences, but we've all covered basic arithmetic conventions at
>> school.)
>
> Is this basic arithmetic:
>
> int result = 8 / 2 * (2 + 2);
>
> You'll be amazed to find that even top notch mathematicians will tell
> you that the result of this statement is ambiguous. Order of evaluation
> is very important here.
>

If it were written as mathematics, exactly like that, it /would/ be
ambiguous. Writing mathematics you have a lot more freedom to make the
meaning clear (especially when using pencil and paper), and you are
writing for human readers rather than dumb computers. So you'd write:

8/2 × (2+2)

or

8
---------
2 × (2+2)

You don't need parenthesis because in written mathematics, size of
spacing /is/ significant.

Written as C code, the statement is not ambiguous - but it /is/ unclear
and can easily be misinterpreted when reading. I think pretty much any
C programmer, when thinking about it, will get it right - but the more
you have to think, the more likely you are to get it wrong.

On 26/04/2022 23:30, bart c wrote:
> On Tuesday, 26 April 2022 at 15:58:41 UTC+1, Ben wrote:
>> David Brown writes:
>
>>> board & 1 << (rows * COLS + col)
>> Ta. That tells me what priorities you think people may confuse. If I
>> had to add a pair, I'd have gone with
>>
>> board & (1 << rows * COLS + col)
>>
>> since I would assume that a lot of C programmers know some C++ and
>> therefore know that one never has to parenthesise basic arithmetic in
>> C++ output expressions.
>
> << isn't basic arithmetic.

C++ programmers are used to seeing statements like :

cout << stuff << more stuff << even more stuff;

Ben's thought here is that they are used to this pattern, and will
automatically think of the "basic arithmetic" parts (which does not
include the "<<" symbol) as being handled first, with the << symbols
separating them much like the commas in function call syntax. Thus
there is no need to parenthesise "rows * COLS + col" within the shift
expression because people familiar with C++ will already see << as low
precedence.

I have at least two objections to this concept, however. First, in some
types of coding - such as the small-systems embedded world for which
MISRA is relevant - you very rarely see iostreams for output in C++
programming. Standard iostreams are just too much overhead - even
standard "printf" is often too big and too slow.

Secondly, it is (IMHO) a mistake to think << has very low precedence, or
to get used to using it without parentheses. "<<" may have been the
best operator available when iostreams were developed, but it is not
perfect. Consider:

cout << "Equality test: " << x == y << endl;

or

cout << "Masked result: " << x & 0xf0 << endl;

The compiler is going to complain about most such mistakes, fortunately.
However, if you've learned that the "<<" symbols work a bit like
parentheses and you have skipped them for printing "x + y", suddenly you
need them for "x < y" and there's an inconsistency. It is not
necessarily a particularly bad inconsistency, but it is worth considering.

>
>>> I am not sure I would go as far as MISRA would like :
>>>
>>> board & (1 << (rows * COLS + col))
>> They leave it vague. Applying the rule strictly, it would require
>>
>> board & (1 << ((rows * COLS) + col))
>
> The relative precedences of * and + are fairly universal so this is going too far.
>
> But I'd have to go and look up those for & and <<. Parentheses would be a good idea especially for fragments of code that might end up being ported across languages, or posted as 'pseudo-code'.
>

While I /do/ know the relative precedences of these operators, I still
think it is clearer to have some parentheses. You give good
justification - code moves around, between people and even between
languages, and long experience at C programming is no guarantee that a
reader will know the precedences. Even for those that /do/ know, it can
take more mental effort to read the expressions and that's wasted mental
effort.

Apparently this first appeared in comp.lang.c++ in a discussion about
the use of the comma operator, but has since become a classic:

"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live."

And as we all know, psychopaths don't like learning operator precedence
tables :-)

David Brown <david.brown@hesbynett.no> writes:

> You don't need parenthesis because in written mathematics, size of
> spacing /is/ significant.

Is it? Where can I find out about this?

--
Ben.

On 27/04/2022 20:43, Ben wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> You don't need parenthesis because in written mathematics, size of
>> spacing /is/ significant.
>
> Is it? Where can I find out about this?
>

I mean the way you space things in how you write mathematics gives
additional information, in a way that cannot be done in a programming
language.

If you see mathematics written :

10 × 2+3

you'll interpret it differently from :

10×2 + 3

The second one you'll see as 23, and be happy with it. The first one
you might assume the writer meant 50. You might also interpret it as
meaning the writer is sloppy or doesn't really understand what he or she
is writing - that's additional information you gain from the spacing.

If you see :

a - b

you'll treat it as one expression.

If you see :

a -b

you will likely consider it as two independent expressions (all
depending on the context, of course).

I am certainly not advocating using spacing instead of parenthesis in
written mathematics - ambiguious and unclear writing is no better in
written mathematics than in programming or anything else (except perhaps
politics or diplomacy!). But you get extra information from it, and it
is therefore significant.

David Brown <david.brown@hesbynett.no> writes:

> On 27/04/2022 20:43, Ben wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> You don't need parenthesis because in written mathematics, size of
>>> spacing /is/ significant.
>> Is it? Where can I find out about this?
>>
>
> I mean the way you space things in how you write mathematics gives
> additional information, in a way that cannot be done in a programming
> language.
>
> If you see mathematics written :
>
> 10 × 2+3
>
> you'll interpret it differently from :
>
> 10×2 + 3

Where does this come from? It's news to me. Where did you find out
about it?

--
Ben.

On 28/04/2022 11:44, Ben wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/04/2022 20:43, Ben wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> You don't need parenthesis because in written mathematics, size of
>>>> spacing /is/ significant.
>>> Is it? Where can I find out about this?
>>>
>>
>> I mean the way you space things in how you write mathematics gives
>> additional information, in a way that cannot be done in a programming
>> language.
>>
>> If you see mathematics written :
>>
>> 10 × 2+3
>>
>> you'll interpret it differently from :
>>
>> 10×2 + 3
>
> Where does this come from? It's news to me. Where did you find out
> about it?
>

I think you are reading too much into this. To my knowledge, there is
no ISO Mathematics Standard document we can refer to. Written
mathematics is written by people, and read by people, as a method of
communication between humans. The way it is laid out, including the
spacing, is part of that. Spacing can make it clear what the writer
/intended/ even if it is not what what was actually /written/. Humans
can make interpretations like that - a compiler cannot.

On 4/28/22 11:59, David Brown wrote:

> Humans can make interpretations like that - a compiler cannot.

Humans _can_ but not all humans do. I would interpret
10 × 2+3 as (10 x 2)+3
This was the basic rule I learned at the times of primary school.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

On 28/04/2022 12:29, Giovanni wrote:
> On 4/28/22 11:59, David Brown wrote:
>
>> Humans can make interpretations like that - a compiler cannot.
>
> Humans _can_ but not all humans do.  I would interpret
>     10  ×  2+3  as (10  x  2)+3
> This was the basic rule I learned at the times of primary school.
>

That is the rule, yes. But if someone else wrote it with such spacing,
would you not think that perhaps they meant it to be interpreted as
though they had written "(10 × 2) + 3" ? When faced with something that
has a conflict between the layout and the standard rules for
mathematics, you know something is not right - but as a human reader you
need to make a judgement as to what you think is wrong, and correct for
that. And you do this in a different way than a computer or compiler does.