Hi,
> You're not going to convince me that not initializing variables is a good
> thing
Personally, I don't think uninitialized variables are a "good thing" but I
also don't think they're a "bad thing" either.
I'd just like to see it not matter when writing a simple one-off script.
FWIW, C# has gone the way of making initializing
variables simpler and simpler over the years, almost to the point of not
being required.
The fact that PHP fires a warning now is probably enough for anyone writing
any code. If people choose to ignore warnings
they're free to do that. Though I suppose they're also free to fork PHP and
remove the thrown error too :D
> > There's no bug here, nothing is unintentional, and the intent is clear
>
> I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell
> whether or not this code is suffering from a merge conflict, and I cannot
guarantee that whatever type `maybe();` returns
> here works. If at some point the return type of `null` is changed to
`false`, while the assumption of undefined is `null`,
> passing `false` to a nullable typed argument later on will break.
That's what unit tests are for. ;) I can count on one hand the number of
times I've seen a bad merge in my entire 15+ year career,
so that wouldn't be an immediate conclusion I'd come to when seeing
something like this. It's much more likely it would be
intentional than not (without checking the history), but I probably
wouldn't bother in this case. If tests pass, don't fix it... just add
more tests.
> Our ecosystem of static analysers are fantastic, but they're standalone
> tools outside the remit of internals.
I think you hit the nail on the head Mark. I'd really love to see PHP have
a bundled static analysis tool.
Robert Landers
Software Engineer
Utrecht NL
On Sat, Jan 29, 2022 at 11:55 PM Lynn <kja...@gmail.com> wrote:
> On Sat, Jan 29, 2022 at 8:58 PM Christian Schneider <cschn...@cschneid.com
> >
> wrote:
>
> > Am 29.01.2022 um 20:03 schrieb Mark Randall <marand...@php.net>:
> > > On 29/01/2022 16:33, Christian Schneider wrote:
> > >> If a static analyzer manages to catch it at development time then that
> > is a lot better.
> > >
> > > Of course it's better, but you wouldn't argue that a car doesn't need
> > airbags because you've tested that the breaks work.
> >
> > To stay with your car analogy: A driving assistant system (especially
> when
> > wrongly interpreted as auto-pilot) can lead drivers to not paying
> attention
> > to the road any more. Which means even systems designed to help can have
> > negative effects.
> >
> > > With runtime checking, the engine should always try to protect against
> > the unexpected, irrespective of if other checking has already been
> > performed by outside sources.
> >
> > I think we've been over this: I don't think the engine should force me to
> > write too much unnecessary stuff just because I have to tell it I am
> sure I
> > mean what I wrote. There is a balance between explicit declarations and
> > conciseness, we just disagree where the sweet spot is.
> >
>
> To stay with the car analogy: Seatbelts were once considered unnecessary as
> well.
>
> Just because you know for sure you know you mean what you wrote, doesn't
> mean everyone else knows. They have to read the code you didn't write to
> know for sure.
>
> On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider <cschn...@cschneid.com
> >
> wrote:
>
> > Am 26.01.2022 um 18:37 schrieb Lynn <kja...@gmail.com>:
> > > I don't understand how variable initializers are considered boilerplate
> > and make it easier to read without.
> >
> > [off-list as I think this has been discussed before]
> >
> > Example:
> >
> > function count_words($words)
> > {
> > foreach ($words as $word)
> > $counts[$word++];
> >
> > return (array)$counts;
> > }
> >
> > vs.
> >
> > Function count_words($words)
> > {
> > $words = []; # <-- Boilerplate
> > foreach ($words as $word)
> > {
> > $counts[$word] ??= 0; # <-- Currently worse boilerplate
> > but beside your point
> > $counts[$word++];
> > }
> >
> > return $counts;
> > }
> >
> > I find the first version easier to understand but I guess we'll have to
> > agree to disagree here.
> >
> > Regards,
> > - Chris
>
>
> I would appreciate it if you keep the replies to the mailing list. Though
> while I'm at it, your examples are why it's important that we have PHP to
> let us know when things are broken.
>
> You're not going to convince me that not initializing variables is a good
> thing, I've had to fix way too much code where that kind of cowboy coding
> was at fault. As a reader I cannot see if the lack of a variable
> initialization is intentional, so I have to go through the history of the
> file to verify this behavior, and then I add the initialization so the next
> developer seeing this won't have to waste a lot of time by doing the same.
>
> A huge amount of changes in PHP are based on what other languages do (or
> sometimes rather don't). With the amount of the web that PHP powers, it's a
> good thing that PHP grabs the good bits and improves itself. Ensuring that
> variables are properly initialized is one of them, as it protects the
> developers from making preventable mistakes without requiring external
> tools.
>
