On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider <cschn...@cschneid.com> wrote:
> My experience is quite the opposite: Systems will stay on older PHP > versions for much longer so they do not having to deal with the work. > Especially for shared hosting services. > Which is even worse in my books. Projects that are not being actively developed, nor being improved to work with newer php versions shouldn't block the future of PHP. On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider <cschn...@cschneid.com> wrote: > > This is where we disagree: I think being able to use undefined variables > and indices avoids boiler plate code and can make it easier to read. > How do you determine that a missing variable initializer isn't a bug or broken merge? I encountered this as recently as yesterday. It's easy to miss, hard to find out what the actual code is supposed to be doing while you're digging through your commit history. Especially when working on bigger applications with more contributors this can lead to a serious issue. Luckily the bug I fixed didn't have any big implications, but it could've just as easily been a mistake costing thousands of euros. I don't understand how variable initializers are considered boilerplate and make it easier to read without. It makes things unclear and unpredictable, and can unintentionally change behavior of your code when not being cautious. Considering "easier to read" is being taken quite literally here, I'll change it to "easier to understand". When in the future, either tomorrow or in 5 years, a developer reads my code, the last thing that developer wants is to make assumptions of how the code is supposed to work when things are seemingly missing. That said, my focus is on variables. Imo index initializers are part of a bigger discussion that encompasses (dynamic) data structures and shouldn't be treated the same.
