Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Improve PHP syntax #228

Merged
merged 2 commits into from
Mar 30, 2024
Merged

fix: Improve PHP syntax #228

merged 2 commits into from
Mar 30, 2024

Conversation

smnandre
Copy link
Contributor

Another set of small improvments:

  • Use=== over ==
  • Use strict types over isset or empty
  • Use spreads over array_merge (better performance)
  • Use multiline docblocks over inlined

@smnandre smnandre force-pushed the fix/php-improvments branch from ed7047a to e5427a5 Compare March 17, 2024 19:43
Copy link
Owner

@meyfa meyfa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • === over == is a welcome change, so are the docblocks and spread syntax.
  • Please avoid Yoda conditions, i.e., prefer $params === null over null === $params.
  • I would prefer if we continued using empty($array) instead of $array === []. In many languages this would perform an identity compare and would always return false, so having this syntax may be confusing DX. Also I did some microbenchmarking comparing the two options and empty($array) is consistently 2.34x faster.

@smnandre
Copy link
Contributor Author

Please avoid Yoda conditions, i.e., prefer $params === null over null === $params.

Oops sorry, it's an habit. Would you agree if i add a phpcs rule to enforce "no yoda condition" ?

I would prefer if we continued using empty($array) instead of $array === [].

Then i'll change back :)

In many languages this would perform an identity compare and would always return false, so having this syntax may be confusing DX.

In PHP any empty array === [], but i understand what you mean for people using often other language. The original goal here was to enfore strict types (stating in those example this value cannot be a bool, null, empty strings etc)

Also I did some microbenchmarking comparing the two options and empty($array) is consistently 2.34x faster.

That in fact is really surprising to me... i made two small benchmark here so you can see

TL;DR; they are absolutely identical

Mulitple arrays (empty, one element, multipes)

Both produce the same exact code after the same number of ops

number of ops:  33
compiled vars:  !0 = $foo, !1 = $foo2, !2 = $foo3, !3 = $foo4

With a single empty array

There again you can see the compiled code is the same (same number of ops)

number of ops:  5
compiled vars:  !0 = $a

So neither of them has a technical / performance one here :)

But it's your lib, so it's your code style and i'll happily use the CS you want 😃

@smnandre smnandre force-pushed the fix/php-improvments branch from f4fac64 to 53d067a Compare March 24, 2024 21:24
@smnandre
Copy link
Contributor Author

Apply your feedback and rebased :)

@smnandre smnandre requested a review from meyfa March 24, 2024 21:25
@meyfa
Copy link
Owner

meyfa commented Mar 28, 2024

Would you agree if i add a phpcs rule to enforce "no yoda condition" ?

Absolutely, if you know how 😅 I found phpcs weird to work with and the available rules kind of limited. Feel free to suggest improvements to our rules as you see fit. (Preferably in a new PR)

@meyfa
Copy link
Owner

meyfa commented Mar 28, 2024

Thank you for benchmarking as well, the site you linked is certainly better suited than what I used when creating mine, and the VLD tab is nice. However, I think your benchmarks are flawed since they execute only 4 comparisons, leading to no observable time difference since the overhead of running the overall PHP script is too large. I adapted your benchmarks to run the comparisons for many more iterations and there you can clearly see a time difference:

$array === []: https://3v4l.org/2qHoa/perf

  • User time: 0.262 seconds

empty($array): https://3v4l.org/vBDue/perf

  • User time: 0.187 seconds (1.4x faster)

The difference isn't as pronounced here as in my previous benchmark, and in general, both operations are quite fast. This probably borders on unnecessary micro-optimization in any case.

By the way, looking at the VLD tab, there are different instructions used here:

  • $array === []:
13        FETCH_DIM_R                                      ~16     !4, ~15
14        IS_IDENTICAL                                             ~16, <array>
  • empty($array):
13        ISSET_ISEMPTY_DIM_OBJ                         1          !4, ~15

So in fact, empty() uses one fewer instruction.

Again, it likely doesn't matter much and I agree with you that the strictness of === [] has some advantages as well. However, I still prefer empty() in this case, mostly for the syntax/DX reasons.

@meyfa
Copy link
Owner

meyfa commented Mar 28, 2024

Thank you for bearing with me throughout this back-and-forth, and sorry for the many delays.

Once the 0 vs. 0.0 thing is resolved this is good to go from my side.

@meyfa meyfa changed the title fix: PHP improvements fix: Improve PHP syntax Mar 28, 2024
@meyfa
Copy link
Owner

meyfa commented Mar 28, 2024

One last thing, just as a note to why I keep changing the PR titles: I'm trying to establish Conventional Commits throughout this project, which requires a title of the form <type>: <description> where <type> can be fix/feat/chore/docs etc. and <description> should start with an imperative verb.

@smnandre
Copy link
Contributor Author

Would you agree if i add a phpcs rule to enforce "no yoda condition" ?

Absolutely, if you know how 😅 I found phpcs weird to work with and the available rules kind of limited. Feel free to suggest improvements to our rules as you see fit.

Forgot you use PHPCS ... i'll look soon to see how to do this :)

(Preferably in a new PR)

:)

@smnandre
Copy link
Contributor Author

One last thing, just as a note to why I keep changing the PR titles: I'm trying to establish Conventional Commits throughout this project, which requires a title of the form <type>: <description> where <type> can be fix/feat/chore/docs etc. and <description> should start with an imperative verb.

Oops sorry. I promise i'll try to think about it.... 🤝

@smnandre
Copy link
Contributor Author

Thank you for benchmarking as well, the site you linked is certainly better suited than what I used when creating mine, and the VLD tab is nice. However, I think your benchmarks are flawed since they execute only 4 comparisons, leading to no observable time difference since the overhead of running the overall PHP script is too large. I adapted your benchmarks to run the comparisons for many more iterations and there you can clearly see a time difference:

$array === []: https://3v4l.org/2qHoa/perf

* User time: 0.262 seconds

empty($array): https://3v4l.org/vBDue/perf

* User time: 0.187 seconds (1.4x faster)

The difference isn't as pronounced here as in my previous benchmark, and in general, both operations are quite fast. This probably borders on unnecessary micro-optimization in any case.

By the way, looking at the VLD tab, there are different instructions used here:

* `$array === []`:
13        FETCH_DIM_R                                      ~16     !4, ~15
14        IS_IDENTICAL                                             ~16, <array>
* `empty($array)`:
13        ISSET_ISEMPTY_DIM_OBJ                         1          !4, ~15

So in fact, empty() uses one fewer instruction.

Again, it likely doesn't matter much and I agree with you that the strictness of === [] has some advantages as well. However, I still prefer empty() in this case, mostly for the syntax/DX reasons.

What an objective and instructive answer, thank you!

No problem for empty as i said it's your repo :))

@smnandre
Copy link
Contributor Author

Absolutely, if you know how 😅 I found phpcs weird to work with and the available rules kind of limited. Feel free to suggest improvements to our rules as you see fit. (Preferably in a new PR)

Would you want to switch to Php-Cs-Fixer ?

@smnandre smnandre requested a review from meyfa March 29, 2024 00:11
@meyfa meyfa merged commit 170cd84 into meyfa:main Mar 30, 2024
7 checks passed
@meyfa
Copy link
Owner

meyfa commented Mar 30, 2024

Would you want to switch to Php-Cs-Fixer ?

Yes, that looks like a good alternative!

@smnandre
Copy link
Contributor Author

Ok i'll see what i can do :))

Could you make me a list (if you have it in mind) of code-style rules you're attached to ? :)

@meyfa meyfa mentioned this pull request Mar 30, 2024
@meyfa
Copy link
Owner

meyfa commented Mar 30, 2024

@smnandre See #229

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants