[Discuss] php dev's code with warnings and notices

[jabr at blu.org (John Abreau)]

When I develop php code, I depend on apache's error_log to diagnose
problems. If the page outputs *anything* to the error_log, then as far as
I'm concerned, the code is broken, and I continue working on it until it no
longer adds to the error_log.

I've never done any programming as part of a team; all my projects have
been solitary efforts, and all the cases where I had to deal with a sloppy
coder's error_log junk were situations where I was a sysadmin, not a member
of the programming team.

If I had to develop code as part of a team, and there were sloppy coders on
the team who don't care if their code pollutes the error_log, I'd want to
find a way for them to feel the pain. As Rich Braun mentioned earlier in
the thread, one possible approach would be to expose the pollution via the
unit tests.




On Sun, Jul 27, 2014 at 10:41 PM, Tom Metro <tmetro+blu at gmail.com> wrote:

> Eric Chadbourne wrote:
> > The code they have...has a bunch of warnings and notices in the logs.
> > I personally think this is sloppy coding.  My question is, how strong
> > a stand should I take on this issue?
>
> Part of this is going to depend on how practical it is to achieve "no
> warnings" in PHP code. I don't know the answer to that. But if you are
> accustom to achieving no warnings in your own PHP code, then yes, I'd
> agree this is indicative of sloppy code.
>
> Compiler/interpreter warnings can be a great tool for spotting problems.
> One of the first things I do in web browsers used for development is
> enable strict mode in the JS engine. I do likewise with MySQL. 'use
> warnings' (or the equivalent achieved through other means) is stock
> boilerplate for all Perl code I develop.
>
> I'd never deliver Perl code that triggers warnings. But Perl also gives
> you tools where you have fine gained control to override warnings in
> situations where the best solution to a problem is to bend the rules a bit.
>
> With JavaScript, that's a different matter, as not all browsers agree on
> what constitutes a situation warranting a warning. And there are some
> warnings, like "function doesn't always return a value" that can seem
> superfluous.
>
> As the senior developer, I'd definitely recommend setting the example by
> delivering code free of warnings, and cleaning up the code you happen to
> be touching for other purposes to eliminate warnings, but what you are
> facing is a cultural problem, rather than a technical one, and that can
> take time to change. If you're the only one submitting clean code, and
> your coworkers aren't on board with the value in doing likewise, you may
> find it to be a futile effort.
>
>  -Tom
>
> --
> Tom Metro
> The Perl Shop, Newton, MA, USA
> "Predictable On-demand Perl Consulting."
> http://www.theperlshop.com/
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email jabr at blu.org / WWW http://www.abreau.net / 2013 PGP-Key-ID 0x920063C6
2013 / ID 0x920063C6 / FP A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6
2011 / ID 0x32A492D8 / FP 7834 AEC2 EFA3 565C A4B6  9BA4 0ACB AD85 32A4 92D8