How strict are you in initialising your variables?

I like to run php reporting pretty much all errors, notices, and warnings, and stamp everything out in development before going live. This forces me to be strict about my input validation, highlights any possible unexpected outcomes of unexpected input, and helps me easily see if I’ve mis-spelled any variable names.

I recently worked with a developer who thought undefined variable notices were for someone else. He’d routinely refer to variables that were defined within some conditional code, echo $_POST variables that may or may not exist, would increment variables in loops without initialising first. So there were a lot of notices and I imagine it was hard for him to see what was relevant and what was not.

How to other people roll?

I’m kind of with you. A variable should ALWAYS be created with some kind of initial value. I’ll admit that I’m an old windoze guy so not initialising your variables would cause ALL KINDS of wierdness so now I’m just used to doing it.

Having said that, some of the things you said this other developer is doing would seem to me to create programs with some very odd intermittent bugs that would be difficult to track down.

DEV with all notices and everything showing. Turn it off in LIVE.

All those notices still are likely being logged, really slowing the server down.

Its a really pi$$poor practice to ignore them, sorting them out invariably lead to finding errors that would otherwise appear elsewhere and lead you discover practices which reduce them from happening anyway - like routinely declaring your variables as mattgoffrey has mentioned.

Nice to know the community is with me. Sometimes I need a reality check to check that I don’t disapprove of a practice because it’s not my practice.

error_reporting has to be set to -1 on my dev machine, there is no other way. For the very reasons every one mentioned already in this thread. Plus it’s not that hard as people make it out to be. Sure, it will be considered nagging from PHP at first, but one you get used to it you wish you’d switched sooner (speaking from experience), because it just makes live so much easier and your code so much more readable :slight_smile:

It is against my religion to not define or check if some type of global is defined before usage. You know what they say about assumptions…

Previous messages have convinced me to use error reporting while developing. This is what I am using:


 ini_set('display_errors',1);
 error_reporting(E_ALL | E_STRICT);

Is that good to use or have I missed something?

Now back to the main topic of this thread:

What variables should be defined at the start of programming?

Please provide an example.

I don’t see anything you have missed as PHP comes compiled with E_ALL and E_STRICT by default, see the below for examples of good and bad practices when working with variables.

// Bad practice
if ($myVariable) {
    // Do something...
}

// Good practice
$myVariable = '';

if ($myVariable) {
    // Do something...
}

Even better (IMHO) than E_ALL | E_STRICT is -1, which is “all errors, always, even there is comes a newer PHP version along sometime with more error levels, I want those too!”

When I mentioned declaring variables I was thinking mostly in terms of OOP, I should have said properties I suppose.

Sometimes it is handy to do kinda magic-y things with __set() and __get() - but generally I do not use them. Being explicit about vars has become part of my “do not write any documentation if you can avoid it” strategy.

I always define everything before I use it.
I always develop with error_reporting(-1). Unless a colleague turns it off secretly and I find out months later that his code is throwing lots of notices >.<

The only reasons I will ever turn off error_reporting is for:

  • Production
  • force-compiling a bunch of templates for gettext purposes

Even if you turn off display_errors for production (which, of course, you really really should do), you can still set the error_reporting level to log (but not display) whatever errors you choose. Even in production the error log is useful for debugging errors, and the less that’s in there down to lazy coding (uninitialised variables etc) the easier it is to track down the actual problem.

You can suppress errors with @ next to any variable or function, but it’s foolish to ignore those errors. I rarely do this when I can’t guarantee an input variable will always be there. For example, if I did used the list() construct on an array created from an exploded string, I’ll suppress it because I know how my variables will be handled at the next step whether or not they are there.

At any other times, I will always use the isset() construct for checking that variables exist.

This is an aside, but it is related to the OPs question. I posted it originally in another thread, but Scallio pointed me here as a related question.

I’m wondering if there was any known vulnerability in PHP if you do not declare a variable, and if so, if someone could point out a situation that this might be the case. (Please be clear - I’m still learning.)

Turning on error display and reporting all errors while developing is always a good idea IMO. I prefer stamping out any errors ahead of time. There is some overhead to printing errors in the log so that is a valid concern.

As far as declaring variables, if you come to PHP from other languages, you may already have good habits regarding that. If you hope to learn other languages that have more strict rules for variables including typing, you may want to force a discipline upon your coding where you declare variables at the top at all times and when possible force cast them for type even though that isn’t functionally necessary in PHP.