PHP Warnings – Is It Good Practice to Avoid Warnings and Notices?

PHPwarnings

I've generally been working with PHP warnings and notices off, since I work on a lot of projects where it's already in live production. Now, if I turn on the warnings and notices on these live production websites, they'll be overloaded with them.

The projects that I work on at home, on local, I usually try to work away ALL warnings and notices. Sometimes, there's no solution to not having a notice, so I'd just have to deal with looking at the notice until I decide to turn them off altogether.

In the end, I don't know whether I'm wasting my time trying to get rid of all warnings and notices, or that I'm actually doing this for the greater good.

Hence my question, is it good practice to avoid warnings and notices altogether, or does it really not matter?

Best Answer

if I turn on the warnings and notices on these live production websites, they'll be overloaded with them.

You should always have warnings turned on to the fullest level in development, testing, and QA, but not in production. Actually, if it's a dogfooding application, i.e. an application that you use yourself, then you should also have them turned on in production.

Basically: have them turned on in those cases where the person who sees them is in a position to do something about them (the developer in development and testing can fix them himself, the tester in QA can file a bug, and if the developer is also the user, then he can also fix it in production), but don't turn them on when the person who sees can't do anything about them (a user in production, who doesn't even know how to program).

Ideally, you'll also want to turn on treating warnings as errors, but that only works if there are none to begin with ;-) But keep this in mind as a goal! If it is possible to turn this on/off on a per-file basis, turn it on for all new files, and turn it on for all warning-free files, and never turn it off again once turned on.

So, what to do about the overload?

You make a list of every warning and notice, and then adhere to the following rules:

  1. Never, ever, under no circumstances add a new warning to the list. Every new piece of code, every edit, every change, every patch, every commit must not introduce new warnings, it may only ever fix them.
  2. Everytime you touch a piece of code, fix any and all warnings in that piece of code. (The Boyscout Rule: always leave the campsite in better condition than you found it.) That way, the un-important code can stay full of warnings, but the important code will get cleaner over time. "Piece of code" may be a function, a class, a file. You may also relax this rule to say to fix at least one warning. The point is: fix them as you find them.

Note: both of these require that you have some sort of log database and log filtering mechanism in place. Note also, that "log database" and "log filtering mechanism" could just be a text file and grep.

This is the important bit. Without the database, you won't know when you add a new warning, and without the filtering, you still have the overload problem.

Note #2: this doesn't only work for warnings, it also works for style checkers, complexity metrics, code coverage, static analysis tools, and so on. Basically:

  1. Don't add new problems.
  2. Fix old problems as you stumble across them.

This allows you to easily prioritize: code that is edited often and thus needs to be easy to read and maintain, will get better over time. Code that isn't touched often, won't get better, but that's okay, because nobody needs to look at it anyway. And, at least it won't get worse.

Of course, nothing stops you from allocating time specifically in order to do nothing but hunt down and kill warnings. It's just that often, this isn't economically viable, and it is your job as an engineer to keep that in mind. "An engineer is one who can build with a dollar, what any fool can build with two."

Related Topic