Is it worth fixing every little PHP warning?

[londrum]

I recently went through my site with a fine tooth comb, looking for every little error and pixel out of place, and noticed that i've got about a bazillion PHP warnings coming up.
these are not proper errors -- the pages all work perfectly fine. they are just little warnings like "this variable hasn't been declared before using it" and stuff like that -- lazy coding.

in an ideal world i would fix all of them. but a) i would rather spend the time writing content, and b) i'm too lazy! i figure that they aren't actual errors, and don't affect the site, so there's no harm in leaving them.

but i'm wondering... what is the point of PHP warnings? what do you actually gain in fixing them? do you save a little bit of memory? does the page load a few nanoseconds quicker? is it worth my time fixing them?

[Readie]

Getting rid of them will make your error logs much easier to use. Can't answer on the performance impact though.

[g1smd]

In fixing them, you'll find a few things that do really matter and find better ways of doing some of them.

[swa66]

Maintainability of your code alone warrants to get rid of every last warning you can find.

You will in the long run spend much less time/money on clean code.

[DrDoc]

I tend to ask myself:

- If I went to buy a car, would I rather drive one where they tried to fix every little detail, or one where they only cared about fixing things that would cause an accident?

- If I am to see a doctor, would I rather see one who is concerned with my general health, or one who only cares about keeping me from immediate death?

While these two examples are certainly extreme, is there really a reason not to code right or not to fix every little warning? Are there benefits to lazy or sloppy coding?

Honest consideration will reveal that you are much better off addressing all the issues. Clean code is easier to work on and maintain, as has already been said. But sloppy code is also prone to errors or other more subtle mistakes. It might work now, but a future code modification may cause nasty creeping problems.

[londrum]

you're probably right, but i think the analogy is more like this:
one day your wife spends an hour getting ready before she goes out, and on another day she takes ten minutes. she still looks alright, so what's the difference? you've just wasted 50 minutes doing something that no one notices.

i think i agree with you though, i'm just being too lazy to fix them!

[brotherhood of LAN]

How long would they take to fix?

I'd fix them if it wasn't a huge job. Getting warnings about deprecated methods is fair enough, but warnings in themselves shouldn't be there to begin with.

I used to like bunching stuff into one line like
implode(',',array_reverse(explode('.',$_SERVER['REMOTE_ADDR']))); ... but apparently newer versions of PHP don't like that.

[DrDoc]

I used to like bunching stuff into one line like
implode(',',array_reverse(explode('.',$_SERVER['REMOTE_ADDR']))); ... but apparently newer versions of PHP don't like that.

That's when you add a method to your utility library. Then you break it out and assign the result to arrays and scalars.

In that case, compliance makes for code that is much easier to read, maintain, and expand.

I really don't see what the drawback is ...

[brotherhood of LAN]

Both the OP and I were talking about old code.

It wasn't so long ago that PHP's OOP wasn't as memory friendly and still a work in progress.

[lucy24]

Aren't they analogous to wmt "errors"? Look at what it says and decide whether you need to do something about it.

For example: you've got code that says "if such-and-such exists, do A; otherwise do B". The php error log file on my MAMP installation racks up a Warning every time such-and-such is found not to exist. Well, yeah. The only way to find out if it exists is to look for it. It doesn't necessarily mean you did something wrong. "I'm just sayin'..."

[JD_Toims]

Is it worth fixing every little PHP warning?

Nope -- The time I spent fixing PHP warnings that have no impact on visitors could be much better spent doing something to improve forward-facing interactions visitors actually know about and use, or building a new site, or fixing something that's actually broken.

I guess the bottom line for me is: I don't build sites to make PHP happy. I build sites for visitors to use and enjoy, so as long as they work the way they're intended I really couldn't care less about PHP's warnings.

[hugoramirez]

I agree with the general sentiment. I think the only time you should care about PHP warnings is if you plan on releasing some source code into the wild for other people to use. Otherwise, they will come back with the warning string and not really understand what it is, or will understand what it is and just complain about the code being "bad", and you'll end up fixing it at that point anyway.

I'm with lazy programmers anywhere - if it works and isn't being emitted to the browser, there's no need to fix it!

Warnings show up because the PHP team will eventually deprecate support in some future release several years from now. At least that's the theory. But I ask myself, "Will this code still be in use 5 years from now?" And, more often than not, the answer is "no".

[penders]

Look at what it says and decide whether you need to do something about it.

Exactly.

PHP Warnings are just that, they are warning you of something that might be a potential error. But the compiler is unable to determine whether it is serious or not - that is for you to decide. A "Warning" could be the result of a serious error in your code, or it might be by design (or at least expected).

"this variable hasn't been declared before using it"

Failure to initialise a variable could be because your initialisation code hasn't executed correctly, or at all. Or, if your code follows a different path then the variable does get initialised... to something you weren't expecting? But only you will know for sure (and that is also a problem).

If you are working with other developers, or you are sharing your code then you really need to resolve these warnings. And as mentioned above, by eliminating these warnings, it will make development/debugging a lot easier.

I used to like bunching stuff into one line like
implode(',',array_reverse(explode('.',$_SERVER['REMOTE_ADDR']))); ... but apparently newer versions of PHP don't like that.

Not sure why newer versions of PHP don't like that? (It works OK for me.)

[brotherhood of LAN]

I used to like bunching stuff into one line like
implode(',',array_reverse(explode('.',$_SERVER['REMOTE_ADDR']))); ... but apparently newer versions of PHP don't like that.

Not sure why newer versions of PHP don't like that? (It works OK for me.)

I can't remember what nested functions I used, as I've removed all my warnings :o) Basically it was a bunch of nested function calls like my example.

[JD_Toims]

...as I've removed all my warnings :o)

Traitor, you've gone to the "dark side" -- That's so *not* right!
Generate a warning for something, Now, and like it! LOL

[Readie]

Not sure why newer versions of PHP don't like that? (It works OK for me.)

Strict reporting gives complaints here I believe. It's because one of the functions is expecting a reference for a parameter, and by definition, a reference cannot be a function call.

[penders]

I can't remember what nested functions I used, as I've removed all my warnings...

(Only just seen Readie's reply as I was about to post, anyway...) Yes, as Readie states, if one of these functions required a pass-by-reference parameter then trying to pass in the output of a function would result in an E_STRICT message as of PHP 5. Although in the above example, this is not the case. However...

echo array_pop(explode('.',$_SERVER['REMOTE_ADDR']));

...would result in an E_STRICT message (providing these are enabled in error_reporting).

[penders]

Just remembered... I was recently debugging someone's customised WordPress install and came across this little E_NOTICE (not an error or even a warning) tucked away in the error log (once I'd enabled full error_reporting)...

Notice: Use of undefined constant WP_ADMIN - assumed 'WP_ADMIN' in ...

Which related to this nugget of code...

// If we are in the admin section... 
if (WP_ADMIN == true) { 
  /* Do some secret admin only stuff here... */

Ouch! Moral of the story is you must at least check every warning and notice!

[brotherhood of LAN]

Yep that's it penders, I come across it intermittently with the way I code things up.

Only variables should be passed by reference

cause: substr(array_shift(explode('.',self::$ref['phone'],2)),1)

I tend to avoid warnings as you never know when something when will become deprecated or worse.

Luckily sed/grep can quickly sort issues with older code quickly enough.

[coopster]

I'll tell you one time you will wish you were addressing all the little errors if you don't practice it already and that is converting pages from the output buffer. Ever seen what a simple notice or warning error does to a PDF document?