On Wed, Jan 26, 2022 at 3:48 PM Christian Schneider <cschn...@cschneid.com> wrote:
> I do not think we should make undefined variables (and array indices?) an > error: 1) Static analysis has gotten a lot better and catches most of this, often > even earlier than the runtime check. > 2) Hot take: I still consider the well-defined constructs like $count++ or > $counts[$word]++ to be useful. That's why we actually patch our PHP to not > emit warnings for undefined variable or index ... > 3) ... which could be impossible at some point once the engine internally > makes assumptions that the program does not continue after an undefined > variable. But then again maybe I worry too much :-) > > I'll vote 'no' on this one again and would ask you to consider leaving > this (like many other things) to the realm of static analyzers instead of > hard-wiring it in the engine, even if you don't use undefined variables > personally. > Far too often I encounter code where I don't know if it was a variable with a typo, a bad merge, or simply incrementing an undefined variable, especially in the context of legacy code. It leaves me with a lot of guessing and side-tracking when trying to find bugs or make changes. Yes this can be enforced by static code analysis, but quite frankly getting tired of having to fight for this in many projects that don't use it. It's much, much harder and costs much more effort to have to convince a whole lot of people all the time of something being better, and having to rely on blog posts that people *might *read. My experience is that people don't care for these rules and recommendations if they are opt-in and in fact make it harder to implement. I don't want to waste time trying to figure out if an undefined `$j++` is a bug because it should've been `$i++`, or that `$i = 0;` is supposed to be unused because someone forgot to remove it. Given the legacy I work with, it's unrealistic to have static code analysis implemented in these projects within a foreseeable time due to the sheer size. Updating PHP to a newer version *will *get development time because we can't stay behind, thus enforcing these good standards. Imo convenience is not a good argument to write code that's potentially bugged and harder to grasp for the reader.
