NYCPHP Meetup

[Mark Armendariz]

On Tue, Aug 19, 2008 at 11:19 AM, csnyder <chsnyder at gmail.com> wrote:
> On Thu, Aug 14, 2008 at 12:00 PM, Mark Armendariz <lists at enobrev.com> wrote:
>
>> I've another project that came in disallowing me to take this project,
>> so I'll likely be moving on - but I'm still largely surprised by the
>> results.  If I had the time to keep a blog, this would likely be a
>> very long demonstrative post about the issue, including some eventual
>> patches.  Hopefully maybe I still can do that some time soon.
>
> Mark, did they rationalize the MYSQL_STRICT requirement?

It was my own requirement.  I've since panned the project, and moved
on to a couple far more interesting ones so I haven't really taken
this issue much further yet - though I do hope to summarize the whole
issue at some point and publish it somewhere on the internets.

> I did a
> little reading up on that (as I'd never heard of it before this
> thread) and it seems like an interesting decision to make, as it will
> break most INSERT statements where an auto-incrementing field is in
> play.
>
> By most, I mean any that uses the old standard INSERT INTO table
> VALUES ( value1, valuen ); syntax is used.

I haven't had much issue with it, personally.  I've been using
MYSQL_STRICT since late last year.  It took me a couple weeks to get
used to a few constraints. The most annoying is trying to skip over
setting non-null fields on inserts and updates.

Also, I prefer to name my columns on inserts.  It makes the sql far
more legible and easier to debug.

>
> You get protection from zero-dates (no more 0000-00-00 00:00:00
> values), but is there any other real practical value to running MySQL
> in this mode?

Overall, the requirement is strictly for development.  "Protection",
as you mentioned, is key.  I find developing in strict mode (p5 and
mysql) keeps me from making silly mistakes and hence saves time.
Typos are caught (uninitialized vars), I know that my object
properties are handled correctly - or even type checked when
necessary, my method signatures are lined up, and my queries are
tight.  It's a red squiggly-lined spell-check for code that helps me
make sure I don't make any stupid mistakes leaving me time to deal
with my big and ugly ones.

For a small project, strict mode generally isn't too big a deal -
especially for a one-off script and I'm glad PHP allows strict mode to
be shut off, but when a project grows and you find yourself calling
methods and objects from hundreds of places throughout a system, it's
nice to know these things are in place.  An automated test suite might
raise the bar for code a few feet.  And a decent QA team / plan a few
feet more.  Strict mode doesn't necessarily make code any better, but
it can raise the bar a half an inch or so.

The thing that bothers me most here is writing towards strict-mode is
pretty easy.  Quality assurance can be pretty difficult.  Testing
correctly, managing bugs, features and project scope, writing decent
specifications, more testing correctly, release schedules, database
optimization, proper security, team and project management, source
control, working with designers all to meet a short deadline and a
budget... All these things take a lot of process and practice to get
them to run smoothly, and they still won't.  Relative to that, writing
code to pass the "strict" test is a walk in the park.  Forget the
walk.  It's a swig of good cold beer at a barbecue on a
hot-but-not-humid summer day.  Simple.  Any time I get a code base
that doesn't pass strict, it usually just takes me an hour or two to
get 80% of the code to stop shouting warnings and notices.  And once
these habits are set, coding for strict mode is just easy - and the
habits are, in my mind, worth the benefit.

Of course, when in production, errors are off.  Strict mode is off.
The essentials are logged.  But I know that once it's there, I don't
have to worry about warnings and notices.  I caught all of them early
in the development phase, and likely with the help of my "compiler."
That's what strict mode is there for.

Sorry, I kinda dragged that rant out, didn't I.

Mark