We start with -2 * 3 + 4.

We do not have to memorize precedence here, because we know
it from school. So, we have

prefix - ! * ...
multiplicative * /
additive + -

. To get the full list of the "calculations", as I call
these operations, we just need to add one layer "postfix"
above and one layer "shift" below:

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>

. One can remember the position of those layers by thinking
about the meaning one wants to have to expressions like -a[ 3 ]
and 1 << 2 + 3. The amount of a shift is often expressed
with arithmetic expressions, so we want no parens there.

Now we'll go beyond what I called "calculations":

The results of calculations usually are compared. We rarely
want ( 2 < 3 )+ 1, but more often 2 <( 3 + 1 ).

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=

Though both are quite rare, (x>0)==(y>0) still should be
needed more often than (x==0)>(y==0).

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=

When shifting, in the end, we often mask using "&". So we
want to be able to write "word & 1 << 3" without parens.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &

Sometimes, one might want to write x==0&y==0 without
shortcut evaluation (to avoid a jump-operation), so "&"
has less precedence than "==".

The "and" operation is very similar to multiplication:
0*0=0, 0*1=0, 1*0=0, 1*1=1. The "or" operation is very
similar to addition: 0+0=0, 0+1=1, 1+0=1, 1+1=2.
So, "and" is "multiplicative" and "or" is "additive".
Additive operations have a smaller precedene than
multiplicative operations.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit or |

The bitwise exclusive or is neither clearly additive nor
clearly multiplicative, so it's middle ground, so to speak.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit exclusive or ^
bit or |

The logical operations are "high level" operations, since
one might want to require to bits to be set via x&3 && y&4.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit exclusive or ^
bit or |
logical and &&
logical or ||

The "if" expression is as high level as a statement. One wants
to be able to write: x > 2 && y > 3 ? ... .

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit exclusive or ^
bit or |
logical and &&
logical or ||
if ?:

(Possibly not all details of the grammar of the ternary
operator can be specified using the concept of precedence,
and so one might need to refer to the actual grammar.)

And whatever expression you write, you want to be able to
write it on the right-hand side of an assignment operator
without parantheses.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit exclusive or ^
bit or |
logical and &&
logical or ||
if ?:
assignment =

One exception to this is when you want to write a
sequence of assignments, such as: a=2,b=3.

postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>
comparisons < > <= >=
equalities == !=
bit and &
bit exclusive or ^
bit or |
logical and &&
logical or ||
if ?:
assignment =
comma ,

It might help to add some structure:

calculations postfix [] () ...
prefix - ! * ...
multiplicative * /
additive + -
shift << >>

comp./eq. comparisons < > <= >=
equalities == !=

bit related bit and &
bit exclusive or ^
bit or |

logical logical and &&
logical or ||
if ?:

assignment assignment =
comma comma ,

So one could start out learning the coarse first column
with only six levels by heart, and the "details" from the
seconds column later.

One also can observe that the operators from [] to | are
used to "obtain" values, while the operators from ?: to
, are used to "process" values, and "&&" and "||" are in
between.

(I wrote all of the above from memory, but looked at a
precedence table yesterday.)

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

> Sometimes, one might want to write x==0&y==0 without
> shortcut evaluation (to avoid a jump-operation), so "&"
> has less precedence than "==".

A more common reason (at least in my experience) is when you want to do
a bunch of things and return if they were all successful:

return do_this() & and_that() & the_other();

(though !(do_this() | and_that() | the_other()) is often safer).

--
Ben.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>We start with -2 * 3 + 4.
>We do not have to memorize precedence here, because we know
>it from school. So, we have
>prefix - ! * ...
>multiplicative * /
>additive + -

Or:

We start with -sin( 0 )* 3 + 4.

We do not have to memorize precedences here, because we know
them from school. So, we have

postfix () [] ...
prefix - ! * ...
multiplicative * /
additive + -

.

On 4/12/2022 6:03 AM, Stefan Ram wrote:
> if ?:
>
> (Possibly not all details of the grammar of the ternary
> operator can be specified using the concept of precedence,
> and so one might need to refer to the actual grammar.)
>

Not only. Expressions like

a < b = 5

are formally non-parsable in C, i.e. they are syntax errors. Even though
many C implementations prefer to pretend that they are parsable and
abort later with some other error (e.g. "lvalue required as left operand
of assignment")

The problem with `?:` you hint at is probably of the same nature, i.e.
it is not really a problem with `?:`, but a problem with the non-trivial
way the *assignment* operator is woven into C grammar.

So, the correct thing to say would be: possibly not all details of the
grammar of the *assignment* operator can be specified using the concept
of precedence.

--
Best regards,
Andrey Tarasevich

On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:

> [...]

What for? Use parentheses - that's what they are there for.

Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote:
> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:

>> [...]

> What for? Use parentheses - that's what they are there for.

If you want to use parentheses, you should be writing in Lisp. ;-)

Too many parentheses can make C code difficult to read. Difficult to
read translates to "more bugs". A knowledge of C's precedence levels,
at least to a moderate degree, can help avoid such bugs.

Maybe some day we'll get the compiler warning "unnecessary parentheses".

--
Alan Mackenzie (Nuremberg, Germany).

Alan Mackenzie <acm@muc.de> writes:
>Too many parentheses can make C code difficult to read. Difficult to
>read translates to "more bugs". A knowledge of C's precedence levels,
>at least to a moderate degree, can help avoid such bugs.

When I would see an expression such as "( 3 * x )+ t", I might spend
some time wondering about why the redundant parentheses are there!

Programming jobs in the real world are more often jobs in maintenance
programming than in writing programs from scratch.

A maintenance programmer often has to /read/ code written by someone
else. And when /reading/ expressions, it helps to know precedence
levels, otherwise one might get the meaning wrong and introduce bugs.
When reading code one does not get to decide whether there are
redundant parentheses as a reading aid in the code, because this
decision has already been made. So, one just has to know the rules.

In article <t373kj$1avk$1@news.muc.de>,
Alan Mackenzie <acm@muc.de> wrote:

> Too many parentheses can make C code difficult to read. Difficult to
> read translates to "more bugs". A knowledge of C's precedence levels,
> at least to a moderate degree, can help avoid such bugs.

Not if you insert line breaks and indentation to line up openners
and closers.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 2022-04-13, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Alan Mackenzie <acm@muc.de> writes:
>>Too many parentheses can make C code difficult to read. Difficult to
>>read translates to "more bugs". A knowledge of C's precedence levels,
>>at least to a moderate degree, can help avoid such bugs.
>
> When I would see an expression such as "( 3 * x )+ t", I might spend
> some time wondering about why the redundant parentheses are there!

Maybe it was copy and pasted from a macro expansion, where 3 * x
had come in as an argument.

Extra parens can help with indentation when an expression
is broken up into multiple lines.

given:

a*b*c*d*... + m*n*o*p* + ...

we might do this at first

a*b*c*d*... +
m*n*o*p*... +
...

the terms of the addition go on separate lines. Now suppose
the terms themselves are too long: now what?

a*b*c*
d*... +
m*n*
o*p*... +
...

that's not very good; extra parens improve it.

(a*b*c*d*...) +
(m*n*o*p*...) +
(...)

then:

(a*b*c*
d*...) +
(m*n*o
*p*...) +
(...)

Chances are your editor will handle this automatically.

On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote:
> Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote:
>> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:
>
>>> [...]
>
>> What for? Use parentheses - that's what they are there for.
>
> If you want to use parentheses, you should be writing in Lisp. ;-)

When you write in Lisp, most of the formatting is automatic and almost
always looks good, so you can concentrate on coding.

There are some new developments in this area in the last few years,
like the "parinfer" algorithm. "parinfer" creates a two-way linkage
between indentation and parentheses. Write your code, adjusting
indentation as you go, and the right parentheses materialize
automatically. Or, tweak the parentheses and the indentation fixes
itself accordingly. Google for demos of this.
>
> Too many parentheses can make C code difficult to read. Difficult to
> read translates to "more bugs". A knowledge of C's precedence levels,
> at least to a moderate degree, can help avoid such bugs.

Too much complexity in one expression makes it hard to read. Other
than breaking it up into smaller expression, what can help is to
split it into multiple lines and use indentation.

Parenthesized expressions are much more amenable for splitting across
lines and indenting than pure infix operator expressions.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote:
>> Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote:
>>> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:
>>
>>>> [...]

>>> What for? Use parentheses - that's what they are there for.

>> If you want to use parentheses, you should be writing in Lisp. ;-)

> When you write in Lisp, most of the formatting is automatic and almost
> always looks good, so you can concentrate on coding.

Yes.

> There are some new developments in this area in the last few years,
> like the "parinfer" algorithm. "parinfer" creates a two-way linkage
> between indentation and parentheses. Write your code, adjusting
> indentation as you go, and the right parentheses materialize
> automatically. Or, tweak the parentheses and the indentation fixes
> itself accordingly. Google for demos of this.

I think that would drive me crazy!

>> Too many parentheses can make C code difficult to read. Difficult to
>> read translates to "more bugs". A knowledge of C's precedence levels,
>> at least to a moderate degree, can help avoid such bugs.

> Too much complexity in one expression makes it hard to read. Other
> than breaking it up into smaller expression, what can help is to
> split it into multiple lines and use indentation.

This is a common attitude, and I'm sure it is wrong a lot of the time.
Breaking up a complicated expression _fragments_ it - it spreads it over
a greater number of source code lines, some of which may not be visible
on the screen. While each fragment may in itself be easier to read, the
entire expression has become more difficult.

> Parenthesized expressions are much more amenable for splitting across
> lines and indenting than pure infix operator expressions.

I'm not sure I agree with this, my background being the maintainer of
Emacs's CC Mode.

How about a real world example? In the following (from Emacs's
syntax.c):

if (code == Sendcomment
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
&& (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
(nesting > 0 && --nesting == 0) : nesting < 0)
&& !comment_ender_quoted (from, from_byte, syntax))

, which is a moderately complicated example, extra parentheses around
the operands of the &&s would clutter up the code rather than clarifying
it. Yet the whole expression being on just five lines makes it
relatively easy to understand.

> --
> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

--
Alan Mackenzie (Nuremberg, Germany).

On 13/04/2022 20:09, Alan Mackenzie wrote:
> Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote:
>> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:
>
>>> [...]
>
>> What for? Use parentheses - that's what they are there for.
>
> If you want to use parentheses, you should be writing in Lisp. ;-)
>
> Too many parentheses can make C code difficult to read. Difficult to
> read translates to "more bugs". A knowledge of C's precedence levels,
> at least to a moderate degree, can help avoid such bugs.
>

The challenge with "moderate degree" is that no one can agree where that
lies.

> Maybe some day we'll get the compiler warning "unnecessary parentheses".
>

Or more usefully (IMHO, of course), a warning for overly complicated
expressions that would be better split up. If you are not sure whether
parentheses are necessary or not, or would help some readers and annoy
others, then that's a good clue that separate statements could be a
better arrangement. Local variables are free, after all - mistakes and
misunderstandings are not.

On 2022-04-14, Alan Mackenzie <acm@muc.de> wrote:
> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>> On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote:
>>> Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote:
>>>> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote:
>>>
>>>>> [...]
>
>>>> What for? Use parentheses - that's what they are there for.
>
>>> If you want to use parentheses, you should be writing in Lisp. ;-)
>
>> When you write in Lisp, most of the formatting is automatic and almost
>> always looks good, so you can concentrate on coding.
>
> Yes.
>
>> There are some new developments in this area in the last few years,
>> like the "parinfer" algorithm. "parinfer" creates a two-way linkage
>> between indentation and parentheses. Write your code, adjusting
>> indentation as you go, and the right parentheses materialize
>> automatically. Or, tweak the parentheses and the indentation fixes
>> itself accordingly. Google for demos of this.
>
> I think that would drive me crazy!
>
>>> Too many parentheses can make C code difficult to read. Difficult to
>>> read translates to "more bugs". A knowledge of C's precedence levels,
>>> at least to a moderate degree, can help avoid such bugs.
>
>> Too much complexity in one expression makes it hard to read. Other
>> than breaking it up into smaller expression, what can help is to
>> split it into multiple lines and use indentation.
>
> This is a common attitude, and I'm sure it is wrong a lot of the time.
> Breaking up a complicated expression _fragments_ it - it spreads it over
> a greater number of source code lines, some of which may not be visible
> on the screen.

A large expression won't be visible all at once, eithery way; if it is on
too few lines, they end up long. If we have multiple choices about
how to break it up, we can achieve a best fit.

> While each fragment may in itself be easier to read, the
> entire expression has become more difficult.
>
>> Parenthesized expressions are much more amenable for splitting across
>> lines and indenting than pure infix operator expressions.
>
> I'm not sure I agree with this, my background being the maintainer of
> Emacs's CC Mode.
>
> How about a real world example? In the following (from Emacs's
> syntax.c):
>
> if (code == Sendcomment
> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
> (nesting > 0 && --nesting == 0) : nesting < 0)
> && !comment_ender_quoted (from, from_byte, syntax))

Interestingly, you have unnecessary parentheses there, in the ternary:

a ? (b) : c

b is already flanked by a ? opener and : closer. I will keep those,
and for consistency parenthesize the (c) also.

> , which is a moderately complicated example, extra parentheses around
> the operands of the &&s would clutter up the code rather than clarifying
> it. Yet the whole expression being on just five lines makes it
> relatively easy to understand.

Proposal:

if ((code == Sendcomment) &&
(SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style) &&
(SYNTAX_FLAGS_COMMENT_NESTED (syntax)
? (nesting > 0 && --nesting == 0)
: (nesting < 0)) &&
(!comment_ender_quoted (from, from_byte, syntax)))

There is now consistent alignment. When we scan the left edge, we
don't see funny business like:

code ==
(SYNTAX...
SYNTAX..

I find that the infix operators are best put at the end of the previous
line, so that the left edge always begins with an operand, where we can
have a parenthesis for promoting alignment.

This can be visualized in chunks like this:

if ((...................) &&
(...............................................) &&
(....................................
? (.............................)
: (...........)) &&
(!.............................................)))

It is a regret that the && operators are not vertically aligned.

Not knowing quite where to put the infix operators is just the scourge
of infix:

(if (and (eq code 'sendcomment)
(eq (syntax-flags-comment-style syntax 0) 'style)
(if (syntax-flags-comment-nested syntax)
(if (plusp nesting) (zerop (dec nesting)))
(minus nesting))
(not (comment-gender-quoted from from-byte syntax)))
(then-do-this))

No neet to repeat the "and": just write it once and give it arguments.
line by line, indented to the same column.

If we want to be slightly sneaky, we take advantage of and being a
generalization of if:

(and (eq code 'sendcomment)
(eq (syntax-flags-comment-style syntax 0) 'style)
(if (syntax-flags-comment-nested syntax)
(if (plusp nesting) (zerop (dec nesting)))
(minus nesting))
(not (comment-gender-quoted from from-byte syntax))
(then-do-this))

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Alan Mackenzie <acm@muc.de> writes:
>Breaking up a complicated expression _fragments_ it

Example for the refactor "extract variable" in pseudocode:

return quantity * item_price -
max(0, quantity - 500) * item_price * 0.05 +
min(quantity * item_price * 0.1, 100);

------------------>

const base_price = quantity * item_price;
const quantity_discount =
max( 0, quantity - 500 )* item_price * 0.05;
const shipping = min( base_price * 0.1, 100 );
return base_price - quantity_discount + shipping;

. There is no reason to fall behind the state of the art.
Suggested reading:

Refactoring - Improving the Design of Existing Code
by Martin Fowler,
publishing house Addison-Wesley Educational Publishers Inc.

. Don't worry! It is written in an easy-to-understand way
so that most programmers can get it.

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Alan Mackenzie <acm@muc.de> writes:
>>Breaking up a complicated expression _fragments_ it

> Example for the refactor "extract variable" in pseudocode:

> return quantity * item_price -
> max(0, quantity - 500) * item_price * 0.05 +
> min(quantity * item_price * 0.1, 100);

> ------------------>

> const base_price = quantity * item_price;
> const quantity_discount =
> max( 0, quantity - 500 )* item_price * 0.05;
> const shipping = min( base_price * 0.1, 100 );
> return base_price - quantity_discount + shipping;

> . There is no reason to fall behind the state of the art.

Whatever that might be in this particular matter. In your rearrangement
of code, you have doubled its size. You have increased the number of
operators used from 8 to 10, the number of lines of code from 3 to 5 and
the number of statements from 1 to 4.

Other things being equal, a more concise expression is easier to
understand. No doubt you would here argue that the other things aren't
equal, and I agree there is some merit to that argument.

But the 5-line version is primarily easier for beginners to understand,
who mentally break down program text to smaller units. An experienced
programmer will prefer the 1-statement version - on encountering the
4-statement version she will subconsciously remark "do I have to go
through all this verbiage _again_?".

> Suggested reading:

> Refactoring - Improving the Design of Existing Code
> by Martin Fowler,
> publishing house Addison-Wesley Educational Publishers Inc.

> . Don't worry! It is written in an easy-to-understand way
> so that most programmers can get it.

No worries! I've had a copy of this book for many years, though it's
some time since I've read it. Just because one can refactor code doesn't
mean it's necessarily a good thing to do. Often it is. I think it was
Steve Yegge in one of his blogs who noted that the problem with
refactoring is that it often bloats code size.

--
Alan Mackenzie (Nuremberg, Germany).

Better use a language like C++17 and further where you can redfine
the operator precedence.

Le 16/04/2022 à 16:29, Christian Hanné a écrit :
> Better use a language like C++17 and further where you can redfine
> the operator precedence.

What a nice idea.

On 2022-04-16, Christian Hanné <the.hanne@gmail.com> wrote:
> Better use a language like C++17 and further where you can redfine
> the operator precedence.

Please cite chapter and verse in the C++17 standrad and provide
a minimal sample.

Or else, please FOAD. If you don't know what that means, refer to:

ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1: Fundamental
terms.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <20220416104034.730@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>On 2022-04-16, Christian Hann <the.hanne@gmail.com> wrote:
>> Better use a language like C++17 and further where you can redfine
>> the operator precedence.
>
>Please cite chapter and verse in the C++17 standrad and provide
>a minimal sample.

Maybe he has his own, customized version of C++.

Just like both of us - you and me - have our own, customized versions of
GAWK. Which are pretty much inaccessible to the rest of the world, and all
they can do is look on from afar, with a combined sense of wonder and awe,
with a not insignificant dollop of envy as well.

--
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

Guillaume <message@bottle.org> writes:
> Le 16/04/2022 à 16:29, Christian Hanné a écrit :
>> Better use a language like C++17 and further where you can redfine
>> the operator precedence.
>
> What a nice idea.

C++17 does not allow redefinition of operator precedence. Christian
Hanné is a lying troll.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2022-04-16, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20220416104034.730@kylheku.com>,
> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>On 2022-04-16, Christian Hann <the.hanne@gmail.com> wrote:
>>> Better use a language like C++17 and further where you can redfine
>>> the operator precedence.
>>
>>Please cite chapter and verse in the C++17 standrad and provide
>>a minimal sample.
>
> Maybe he has his own, customized version of C++.
>
> Just like both of us - you and me - have our own, customized versions of
> GAWK. Which are pretty much inaccessible to the rest of the world, and all
> they can do is look on from afar, with a combined sense of wonder and awe,
> with a not insignificant dollop of envy as well.

I'm not sure what you mean by "accessible". I /very/ recently started a
small feature fork of GNU Awk, as in within this past week. It is
publicly hosted, and has updated documentation and test cases. Now it's
not "accessible" the way upstream Gawk is accessible whereby you can
just do "apt-get install gawk" at your Ubuntu prompt, and it's not (yet)
even accessible in the way that you can pull down a gawk-x.y.z.tar.xz
ball, unpack it and build it without needing Automake and Autoconf and
all that (which I will in due time). But it's not "inaccessible".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Saturday, April 16, 2022 at 3:28:00 PM UTC+1, Alan Mackenzie wrote:
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> > Alan Mackenzie <a...@muc.de> writes:
> >>Breaking up a complicated expression _fragments_ it
> > Example for the refactor "extract variable" in pseudocode:
>
> > return quantity * item_price -
> > max(0, quantity - 500) * item_price * 0.05 +
> > min(quantity * item_price * 0.1, 100);
>
> > ------------------>
>
> > const base_price = quantity * item_price;
> > const quantity_discount =
> > max( 0, quantity - 500 )* item_price * 0.05;
> > const shipping = min( base_price * 0.1, 100 );
> > return base_price - quantity_discount + shipping;

How about a compromise?

return quantity * item_price
- max(0, quantity - 500) * item_price * 0.05 // quantity discount
+ min(quantity * item_price * 0.1, 100); // shipping

Paul N <gw7rib@aol.com> wrote:
> On Saturday, April 16, 2022 at 3:28:00 PM UTC+1, Alan Mackenzie wrote:
>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> > Alan Mackenzie <a...@muc.de> writes:
>> >>Breaking up a complicated expression _fragments_ it
>> > Example for the refactor "extract variable" in pseudocode:

>> > return quantity * item_price -
>> > max(0, quantity - 500) * item_price * 0.05 +
>> > min(quantity * item_price * 0.1, 100);

>> > ------------------>

>> > const base_price = quantity * item_price;
>> > const quantity_discount =
>> > max( 0, quantity - 500 )* item_price * 0.05;
>> > const shipping = min( base_price * 0.1, 100 );
>> > return base_price - quantity_discount + shipping;

> How about a compromise?

> return quantity * item_price
> - max(0, quantity - 500) * item_price * 0.05 // quantity discount
> + min(quantity * item_price * 0.1, 100); // shipping

I think that is the best of all! Inserting brief, meaningful comments,
as above, makes the thing easy to understand without bloating the code.
I wish more people would code like this.

--
Alan Mackenzie (Nuremberg, Germany).

On 25/04/2022 11:21, Alan Mackenzie wrote:
> I think that is the best of all! Inserting brief, meaningful comments,
> as above, makes the thing easy to understand without bloating the code.
> I wish more people would code like this.

Absolutely.

It has the great advantage that the comments say what the code is
_supposed_ to do. If they disagree that's a great big alarm bell to
anyone looking for bugs.

"self documenting code" doesn't do that.

Andy

Paul N <gw7rib@aol.com> writes:

> On Saturday, April 16, 2022 at 3:28:00 PM UTC+1, Alan Mackenzie wrote:
>
>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>
>>> Alan Mackenzie <a...@muc.de> writes:
>>>
>>>> Breaking up a complicated expression _fragments_ it
>>>
>>> Example for the refactor "extract variable" in pseudocode:
>>>
>>> return quantity * item_price -
>>> max(0, quantity - 500) * item_price * 0.05 +
>>> min(quantity * item_price * 0.1, 100);
>>>
>>> ------------------>
>>>
>>> const base_price = quantity * item_price;
>>> const quantity_discount =
>>> max( 0, quantity - 500 )* item_price * 0.05;
>>> const shipping = min( base_price * 0.1, 100 );
>>> return base_price - quantity_discount + shipping;
>
> How about a compromise?
>
> return quantity * item_price
> - max(0, quantity - 500) * item_price * 0.05 // quantity discount
> + min(quantity * item_price * 0.1, 100); // shipping

Speaking for myself I would rather see something like this:

[...]
unsigned n = quantity;
double price = item_price;
return sale_charge( n, price ) + shipping_charge( n, price );

double
sale_charge( unsigned n, double price ){
return base_charge( n, price ) - quantity_discount( n, price );
}

double
shipping_charge( unsigned n, double price ){
return min( base_charge( n, price ) * 0.1, 100.0 );
}

double
base_charge( unsigned n, double price ){
return n * price;
}

double
quantity_discount( unsigned n, double price ){
return n > 500 ? (n-500) * price * 0.05 : 0;
}