Re: [RFC] Reclassifying engine warnings

From: Date: Thu, 12 Sep 2019 09:41:36 +0000
Subject: Re: [RFC] Reclassifying engine warnings
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-106935@lists.php.net to get a copy of this message
> Le 12 sept. 2019 à 10:17, Stephen Reay <php-lists@koalephant.com> a écrit : > > > > I’ve seen a number of people that have concerns about PHP throwing actual errors (as opposed > to notices) because they try to use a variable/offset that doesn’t exist, and of course there is > often a proposal to have a declare statement or something similar, to allow their “code style” > to run without errors. > > > So, my proposal to the situation is to introduce a single declare that solves that problem, > once and for all. > > > declare(sloppy=1); > > > This would suppress any errors about undefined variables, array offsets, would reverse the > “bare words" change when encountering an undefined constant, etc. Heck, for good measure this > mode could even re-implement register_globals and magic_quotes, because why not? > > > > If you want to write sloppy code, that is entirely your prerogative, but please just own it for > what it is, and stop pretending that it’s some herculean task to either define variables/offsets > first; or check if they’re defined; or use an appropriate method to access them that specifically > allows for undefined variables/offsets (i.e. the ?? and ??= operators) > > Declare(sloppy=yeah) is not granular enough. To all: please, do understand that everything is not black or white; this remark is not directed specifically to that particular issue, this is an attitude I see regularly on that mailing list. There is no such thing as “one true strict coding standard” and “one legacy lax coding standard”. For instance: * As time passes, we learn by experience what features were plain blunders (magic_quotes?), what features should have been more strict for the sake of catching bugs without imposing too much burden on users, what features could have been more strict, although that would impose to write lot of boiler code, etc. This process does not belong exclusively to some past dark age of sloppy and unsecure coding practices. * The degree of wanted strictness vary depending on occasions. For example when I’m writing a throw-away script, some notices are okay to indicate possible problems, but I’m not going to write boilerplate code (or, worse, put a @ in front of everything) just for the sake of silencing them. (But I *certainly* do not want stupid things like mistyped constants converted to string literals.) On the other hand, when I’m writing a critical part of an application, I am careful to write down everything precisely, and having to write explicitly and once for all that, yes, this precise variable must have that default value, is a minimal part of the time passed to write, re-read and review the code. —Claude

« previous php.internals (#106935) next »