An simplified example from a real project:

if (!($this->action[$key] ?? false)) {

What it means:

1) $this->action[$key] ?? false

This return $this->action[$key] if $this->action[$key] exists and is not
null or "false".

2) !( .... )

Will negate the result - so the condition is true if $this->action[$key]
does not exist or is null.

However to understand this you must know what the ?? operator means and
note the negation using ! in the beginning.

When you did not create this code in the first place or try to find a
bug expressions like this are not really helpful.

I would prefer a longer but easier to understand solution like this:

if (!isset($this->statusActions[$key])
|| null === $this->statusActions[$key]
) {

Any thoughts on this?

--
Arno Welzel
https://arnowelzel.de

On 23/11/2021 11.52, Arno Welzel wrote:
> An simplified example from a real project:
>
> if (!($this->action[$key] ?? false)) {
>
> However to understand this you must know what the ?? operator means and
> note the negation using ! in the beginning.

What if you don't know about === then the null check below looks strange
and you would think it has a bug.

There will always be something you don't know about, but people tend to
learn.

> I would prefer a longer but easier to understand solution like this:
>
> if (!isset($this->statusActions[$key])
> || null === $this->statusActions[$key]
> ) {
>
> Any thoughts on this?

I do prefer the short one, but then I'm used to that kind of code and
the code analyzer at work do complain when you have a lot of if
statements with unnecessary and/or operators.

There can also be code execution gains with the short compact code
compared to do the "traditional" way. There been times where I have
managed to make the code execution 1/100 of the original time using the
shorter compact code.

In the end it's about the head coders taste and maybe company coding
standard that will dictate when you write, it's like some people like
oop while others don't, it don't make the whole world what you pick, as
long as the program works in the end in a safe way. Just look at the
source code for mplayer, the rows are extreme short as the head coder
max screen resolution was 800x600 and wanted to see all lines without
row-wrapping.

--

//Aho

On 11/23/2021 5:52 AM, Arno Welzel wrote:
> An simplified example from a real project:
>
> if (!($this->action[$key] ?? false)) {
>
> What it means:
>
> 1) $this->action[$key] ?? false
>
> This return $this->action[$key] if $this->action[$key] exists and is not
> null or "false".
>
> 2) !( .... )
>
> Will negate the result - so the condition is true if $this->action[$key]
> does not exist or is null.
>
> However to understand this you must know what the ?? operator means and
> note the negation using ! in the beginning.
>
> When you did not create this code in the first place or try to find a
> bug expressions like this are not really helpful.
>
> I would prefer a longer but easier to understand solution like this:
>
> if (!isset($this->statusActions[$key])
> || null === $this->statusActions[$key]
> ) {
>
> Any thoughts on this?
>
>

Arno,

I agree with you. When I was teaching programming to corporate
programmers (mostly C, C++ and Java for languages), I always stressed to
code for clarity over speed. Only if performance is not good enough
should one go back and modify the code. But most compilers nowadays
will optimize the code better than a programmer, anyway.

Of course PHP doesn't have a compiler but I use the same standard.
Clarity before complexity always wins out. And the difference in
performance here will be so minimal that it's not going to make a huge
difference in speed.

The metric I tell them to go by - you should be able to hand the code to
a new programmer in that language and they should be able to tell you
quickly what it does. If he/she can't do that, the code is
unnecessarily complicated.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

Arno Welzel <usenet@arnowelzel.de> writes:

> An simplified example from a real project:
>
> if (!($this->action[$key] ?? false)) {
>
> What it means:
>
> 1) $this->action[$key] ?? false
>
> This return $this->action[$key] if $this->action[$key] exists and is not
> null or "false".
>
> 2) !( .... )
>
> Will negate the result - so the condition is true if $this->action[$key]
> does not exist or is null.
>
> However to understand this you must know what the ?? operator means and
> note the negation using ! in the beginning.
>
> When you did not create this code in the first place or try to find a
> bug expressions like this are not really helpful.
>
> I would prefer a longer but easier to understand solution like this:
>
> if (!isset($this->statusActions[$key])
> || null === $this->statusActions[$key]
> ) {
s/statusActions/action/g
>
> Any thoughts on this?

They are not quite the same as your longer version ignores "falsey"
values other than null. Taking those into account:

if (!isset($this->action[$key]) || !$this->action[$key]) { ...

but then I would just prefer

if (@!$this->action[$key]) { ...

But as for the original, there is something to be said for code that
takes a moment to grok. The real problem is code so obviously correct
that the reader misses the error! Having to work out what a line means
is no bad thing when debugging someone else's code.

--
Ben.

On Tue, 23 Nov 2021 12:17:13 J.O. Aho wrote:
> On 23/11/2021 11.52, Arno Welzel wrote:
> > An simplified example from a real project:

> > if (!($this->action[$key] ?? false)) {

> > However to understand this you must know what the ?? operator
> > means and note the negation using ! in the beginning.

> What if you don't know about === then the null check below looks strange
> and you would think it has a bug.

Knowledge about === should be more widespread than about ??, and at
least for me the latter is less intuitive to read. But ok, this is
really a matter of personal preference.

> > if (!isset($this->statusActions[$key])
> > || null === $this->statusActions[$key]
> > ) {

Personally I would write:

#v+
if (
!array_key_exists($key, $this->statusActions) ||
is_null($this->statusActions[$key])
) {
# something
} #v-

I always give preference to array_key_exists as isset($x[$y])
gives my brain the (false) impression that $x[$y] should exist,
while array_key_exists($y, $x) does not do this.

And I prefer is_null() over "null ===" because it cannot be
misinterpreted or misspelled.

> I do prefer the short one, but then I'm used to that kind of code
> and the code analyzer at work do complain when you have a lot of
> if statements with unnecessary and/or operators.
> There can also be code execution gains with the short compact code
> compared to do the "traditional" way. There been times where I
> have managed to make the code execution 1/100 of the original time
> using the shorter compact code.

I really like verbosity wherever possible, because I don't have to
think about the less important aspects of the code even when looking
at it after 10-15 years.

If I'd lose a factor 100 (or even a factor 10) of execution time
this would certainly make me use shortcuts. However, I don't think
this is likely to happen. Wherever I've lost one or more magnitues
of execution time it was due to avoidable nested loops or otherwise
poor logic.

Bye,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Von Verführern für Verführer - zutschen mit Stefan!
(Sloganizer)

On 24/11/2021 10.57, Stefan Froehlich wrote:
> On Tue, 23 Nov 2021 12:17:13 J.O. Aho wrote:
>> On 23/11/2021 11.52, Arno Welzel wrote:
>>> An simplified example from a real project:
>
>>> if (!($this->action[$key] ?? false)) {
>
>>> However to understand this you must know what the ?? operator
>>> means and note the negation using ! in the beginning.
>
>> What if you don't know about === then the null check below looks strange
>> and you would think it has a bug.
>
> Knowledge about === should be more widespread than about ??, and at
> least for me the latter is less intuitive to read. But ok, this is
> really a matter of personal preference.

Not all languages has the triple-equal, so it could be for some people
as odd as ?? for some other people. It's just that programming languages
tend to evolve over time and also what people thinks is the right way to
do things.
Nowadays we don't use line numbers as in the days when I begun to write
some code at home, sure in the beginning it felt a bit strange to not
have the line number as reference, but now I wouldn't want to go back to
that.

> I always give preference to array_key_exists as isset($x[$y])
> gives my brain the (false) impression that $x[$y] should exist,
> while array_key_exists($y, $x) does not do this.
> And I prefer is_null() over "null ===" because it cannot be
> misinterpreted or misspelled.

I do have to agree here with you, I do prefer the array_key_exists in
this case, just need to check that the array exists before checking if
the key exists.

> If I'd lose a factor 100 (or even a factor 10) of execution time
> this would certainly make me use shortcuts. However, I don't think
> this is likely to happen. Wherever I've lost one or more magnitues
> of execution time it was due to avoidable nested loops or otherwise
> poor logic.

It's more or less never the short-syntax as the one in the original post
would make a noticeable difference, but those short replacements tend to
have the benefit from internal features that makes them faster than the
traditional code.
Loops are generally time consuming and using alternatives to for/foreach
can both make the code shorter and faster, but that depends on the
language and what alternatives it can provide.

But I think we can all agree on that the best code is the code that
works and gives you a result in a reasonable time.

--

//Aho

1 byte contains only 256 bits of information. Everyone make now Your own conclusions.

☏ : 372 5 3 9 0 0 6 6 0
E-mail : he1983912[@]mail.ee

Arno Welzel kirjutas Teisipäev, 23. november 2021 kl 12:52:33 UTC+2:
> An simplified example from a real project:
>
> if (!($this->action[$key] ?? false)) {
>
> What it means:
>
> 1) $this->action[$key] ?? false
>
> This return $this->action[$key] if $this->action[$key] exists and is not
> null or "false".
>
> 2) !( .... )
>
> Will negate the result - so the condition is true if $this->action[$key]
> does not exist or is null.
>
> However to understand this you must know what the ?? operator means and
> note the negation using ! in the beginning.
>
> When you did not create this code in the first place or try to find a
> bug expressions like this are not really helpful.
>
> I would prefer a longer but easier to understand solution like this:
>
> if (!isset($this->statusActions[$key])
> || null === $this->statusActions[$key]
> ) {
>
> Any thoughts on this?
>
>
> --
> Arno Welzel
> https://arnowelzel.de

Actually 1 byte contains 8 bits and can represent a number from 0 to 255

Stan

On 6/30/2022 10:21 PM, See Kes Seda Hetkel Siia Kirjutab wrote:
> 1 byte contains only 256 bits of information. Everyone make now Your own conclusions.
>
>
> ☏ : 372 5 3 9 0 0 6 6 0
> E-mail : he1983912[@]mail.ee
>
>
> Arno Welzel kirjutas Teisipäev, 23. november 2021 kl 12:52:33 UTC+2:
>> An simplified example from a real project:
>>
>> if (!($this->action[$key] ?? false)) {
>>
>> What it means:
>>
>> 1) $this->action[$key] ?? false
>>
>> This return $this->action[$key] if $this->action[$key] exists and is not
>> null or "false".
>>
>> 2) !( .... )
>>
>> Will negate the result - so the condition is true if $this->action[$key]
>> does not exist or is null.
>>
>> However to understand this you must know what the ?? operator means and
>> note the negation using ! in the beginning.
>>
>> When you did not create this code in the first place or try to find a
>> bug expressions like this are not really helpful.
>>
>> I would prefer a longer but easier to understand solution like this:
>>
>> if (!isset($this->statusActions[$key])
>> || null === $this->statusActions[$key]
>> ) {
>>
>> Any thoughts on this?
>>
>>
>> --
>> Arno Welzel
>> https://arnowelzel.de

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Fri, 1 Jul 2022 01:05:37 -0400, Stan Weiss wrote:
> Actually 1 byte contains 8 bits and can represent a number from 0 to 255

Actually s/number/value/

Yes, there are times the value will be looked at as -127 to +127

Stan

On 7/1/2022 8:18 AM, Allodoxaphobia wrote:
> On Fri, 1 Jul 2022 01:05:37 -0400, Stan Weiss wrote:
>> Actually 1 byte contains 8 bits and can represent a number from 0 to 255
> Actually s/number/value/
>

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Fri, 1 Jul 2022 09:08:31 -0400 Stan Weiss <srweiss@erols.com> wrote:
> On 7/1/2022 8:18 AM, Allodoxaphobia wrote:
> > On Fri, 1 Jul 2022 01:05:37 -0400, Stan Weiss wrote:
> >> Actually 1 byte contains 8 bits and can represent a number from 0
> >> to 255
> > Actually s/number/value/
>
> Yes, there are times the value will be looked at as -127 to +127

Actually -128 to +127 because values are evaluated in 2's complement.

Mateusz