Addendum to the D7CX movement

I just spent the entire morning fixing notices and adding patches in the issue queue for a couple of contributed modules we're currently using in a project. On my development box, I always set error_reporting to 'E_ALL' and display_errors to 'On' in php.ini so I can see how good or bad the code is. Drupal core is pretty much free from such notices, but in the contrib world there's a lot of undefined variables and indexes out there. Fixing them sounds boring but is actually pretty fun and you learn a lot about the internals of Drupal core too, so it's really worth spending time on this.

A few months ago Moshe started the D7CX movement encouraging module developers to release a D7 version of their modules the day Drupal 7 is out. Excellent initiative and a lot of module maintainers already made that pledge. That's really wonderfull, but let's hope module maintainers always run with full error reporting and make their modules notice free, so why not change that pledge a bit:

I pledge that mymodule will have a full Drupal 7 release and will be PHP notice free on the day that Drupal 7 is released.

Of course, this still applies to D6 and D5 too, who's in on this too ?

Comments

Submitted by Anonymous jackass on December 21, 2009 - 20:06

To the vast majority of everyone, E_ALL error notices don't matter at all. Not one bit. It's nice to be E_ALL compliant, but it is by no means a necessary step for useful code. In contrast, Drupal 7 will not be successful if modules are not updated to the Drupal 7 API on the day Drupal 7 is released. I would much prefer to have a module that *works* with Drupal 7 on the day it's released than to have one that doesn't and is E_ALL complaint. So I would advise everyone not to delay updating modules for E_ALL compliance, but rather to practice good coding practices so that E_ALL errors don't arise in the first place.

Submitted by Pasqualle on December 21, 2009 - 20:19

practice good coding practices so that E_ALL errors don't arise

It is not humanly possible. If you do not use testing and code validation, then the code will have bugs. swentel is right, if you see a module with full of PHP notices, you should not use it.
And E_ALL compliance does not mean any delay..

Submitted by Anonymous non-g... on December 22, 2009 - 00:02

Paid-by-the-hour workers switch off E_ALL so the code will contain errors that will take a while to show up and a long time to debug. ~E_ALL guarantees you will be back many times for weird bugs. ~E_ALL is a rich profitable source of billable hours. Use ~E_ALL (but not on my sites!).

Submitted by Larry Garfield on December 22, 2009 - 02:37

So I would advise everyone not to delay updating modules for E_ALL compliance, but rather to practice good coding practices so that E_ALL errors don't arise in the first place.

Developing to E_ALL standards in the first place is "good coding practices", by definition. That's the point. E_ALL matters to everyone who wants bug-free modules, which is everyone. Getting a module that works in D7 is easier when you let PHP find bugs for you, which is exactly what E_ALL (and to a tighter degree, E_STRICT) does.

+1 from me. Notices are bugs and should be treated as such.

Submitted by Dave Reid on December 23, 2009 - 17:23

It's absolutely painful to see how many modules (even ones like CCK) have so many PHP notices. Every developer should have notices enabled (yay for getting it on in D7 by default when using a -dev release), and everyone should always report every notice in the issue queues. I prefer to use the name 'PHP notices of shame' for the issue. :)

You are here