Re: [RFC] Reclassifying engine warnings
| From: | Claude Pache | 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