Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #18813 > unrolled thread

Shorter is not always better

Back to article view | Back to comp.lang.php

Contents

  Shorter is not always better Arno Welzel <usenet@arnowelzel.de> - 2021-11-23 11:52 +0100
    Re: Shorter is not always better "J.O. Aho" <user@example.net> - 2021-11-23 12:17 +0100
      Re: Shorter is not always better Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-11-24 09:57 +0000
        Re: Shorter is not always better "J.O. Aho" <user@example.net> - 2021-11-24 15:53 +0100
    Re: Shorter is not always better Jerry Stuckle <jstucklex@attglobal.net> - 2021-11-23 18:42 -0500
    Re: Shorter is not always better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-23 23:48 +0000
    Re: Shorter is not always better See Kes Seda Hetkel Siia Kirjutab <he1983912@gmail.com> - 2022-06-30 19:21 -0700
      Re: Shorter is not always better Stan Weiss <srweiss@erols.com> - 2022-07-01 01:05 -0400
        Re: Shorter is not always better Allodoxaphobia <trepidation@example.net> - 2022-07-01 12:18 +0000
          Re: Shorter is not always better Stan Weiss <srweiss@erols.com> - 2022-07-01 09:08 -0400
            Re: Shorter is not always better Mateusz Viste <mateusz@xyz.invalid> - 2022-07-01 17:13 +0200

#18813 — Shorter is not always better

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

[toc] | [next] | [standalone]

#18814

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

[toc] | [prev] | [next] | [standalone]

#18822

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)

[toc] | [prev] | [next] | [standalone]

#18823

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

[toc] | [prev] | [next] | [standalone]

#18815

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
==================

[toc] | [prev] | [next] | [standalone]

#18816

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.

[toc] | [prev] | [next] | [standalone]

#19020

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

[toc] | [prev] | [next] | [standalone]

#19021

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

[toc] | [prev] | [next] | [standalone]

#19022

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/

[toc] | [prev] | [next] | [standalone]

#19023

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

[toc] | [prev] | [next] | [standalone]

#19024

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web