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

Groups > comp.lang.php > #18823

Re: Shorter is not always better

Show all headers | View raw

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

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web