Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106745
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAJHtznyadHb5_RgjddnPiyeWXtLQyp2CDK=ix=BiEd+DEUHqLg@mail.gmail.com>
 <CAF+90c_94zAj-7XW+=YtZ2VsZEshd4DvNY8_17PyiBXvYR1gdw@mail.gmail.com>
 <CAJHtznw5wOTMA-BUO6hOARxSie75+PwccSocVapHi4k02Z+x0A@mail.gmail.com>
 <CAPKYkKzc37d52ZjHy0ht6Oc_HgoBq4+DandNW1Hk-+x5NnUS7Q@mail.gmail.com>
 <CAPKYkKwhUmq40yGta3+ERfcDOOrkPi5Db6-i7pPMRmV4CrQRTQ@mail.gmail.com>
 <7ddbae5c-7451-4094-8b32-19676128054b@thelounge.net> <CAPKYkKyYvqW9Hm-nae0CXJ98XxRzt7XRpe_+FzeqiJME3K4jug@mail.gmail.com>
 <CAPKYkKw5vxgeM+vq_z9YhNYEMuPodCjfGNv6BRFS+bg0BG-Q0w@mail.gmail.com>
 <CAOkcCt_xsP1AOwB0-nuY4_qwxSc3h8mns_Yax9UnrLzFCN-m+g@mail.gmail.com>
 <CAPKYkKxAkowF_H9gDZg2pDVdUyftJz0b2LAE08jW8jjA6Nq-uw@mail.gmail.com>
 <CADyq6sJd6=2UEXXrad2heYw4Mp876rSQ9ZcKeuXOKEWO8F2saA@mail.gmail.com>
 <CAPKYkKw7Q7A4Z5TkgNX-=LPZZy7_orCRUsULBA7j=wZgKU-VuQ@mail.gmail.com>
 <5d6699ce.1c69fb81.e9b71.2525SMTPIN_ADDED_MISSING@mx.google.com> <CAPKYkKwkyXh64fyTeZeLrZR_kXQ9w9d=skFmqcdWpk=z0HSMxQ@mail.gmail.com>
In-Reply-To: <CAPKYkKwkyXh64fyTeZeLrZR_kXQ9w9d=skFmqcdWpk=z0HSMxQ@mail.gmail.com>
Date: Wed, 28 Aug 2019 18:10:17 +0200
Message-ID: <CAL0xaBHZu3OT=e8gmjJWVjdndVfq4re5qtHoh4ZBV3OstkURhA@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Mark Randall <markyr@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000903bf005912fa1dc"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000903bf005912fa1dc
Content-Type: text/plain; charset="UTF-8"

Hello,

as many later posters in the thread have said - a lot of notices,
especially uninitialised variables, are classic technical debt.

For example, I just recently fixed a bug, that did this: `$array['key'] +=
$cost` - the array key was not initialised. Well, turned out that in this
case instead of null, it actually grabbed some garbage number out of memory
and screwed up the calculations where the total was off by a few hundred
euro. Previous dev did care about notices and/or warnings and god knows how
long that issue was in production and how many calculations it affected
before it was caught.

There is also another side effect on performance. error handling in PHP is
not free - it does take some significant amount of time. And the more
warnings/notices like that you have, the bigger the impact. I have migrated
an old code base that was riddled with notices - just fixing those improved
performance by 100% without adjusting anything else. Single page load
generated 3.5MB of notices and warnings. It also fixed quite a few bugs
just because vars got their proper initial values.

From time to time I get reminded when I go back into the crappy code how
unpredictable it can be.


And the point about PHP 's future. Planning should be done for at least the
next 10 years and in today's environment, PHP needs a stricter mode that is
just across the board. A project that I start today is by default in strict
types mode, PHPStorm has 99.9% of inspections enabled, code analysers are
configured and you will not be able to leave a potentially undefined
variable in my codebase. git commit hook will just reject it.

Frankly, today I do not care what PHP was 5 years ago and how people used
it. I care what PHP is today and will be in 5 years when my app goes into
production and is actively developed. I also dedicate resources in my
budget to keep our software up to date and perform TLC on it. I just do not
allow the business to ignore it. A lot of that TLC is done by just regular
development workflow - you see crap, you take 5 minutes to fix it. A lot of
the time executives don't even know we did the TLC, nor they even should -
that's part of our daily responsibilities.

--000000000000903bf005912fa1dc--