This is a discussion on undefined: good or bad? within the PHP Language forums, part of the PHP Programming Forums category; I decided to run some code with errors set to E_ALL, just to see what I would run across. It ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
I decided to run some code with errors set to E_ALL, just to see what I
would run across. It caught a few things, but 90% or better of the messages were of the 'undefined' kind: PHP Notice: Undefined variable PHP Notice: Undefined index PHP Notice: Undefined property I'd like to go back and fix what I can, but I'm wondering: how good or bad is this? I mean, I rely on the fact that the first use of a variable defines it. However, I'm also very used to "use strict" in perl, so I know that on-the-fly variable declarations can be dangerous. Is there a general rule of thumb for correcting these? Best practice? Do most people not care? If it ain't broke don't fix it? --cd |
|
|||
|
Coder Droid <coderdroid@likethiswouldstopspam.hotmail.com> wrote:
> I decided to run some code with errors set to E_ALL, just to see what I > would run across. It caught a few things, but 90% or better of the > messages were of the 'undefined' kind: [snip] > I'd like to go back and fix what I can, but I'm wondering: how good or > bad is this? I mean, I rely on the fact that the first use of a variable > defines it. However, I'm also very used to "use strict" in perl, so I > know that on-the-fly variable declarations can be dangerous. IMHO I only get undefined warnings if: -I made a typo -I make an potentially conditional error -- Daniel Tryba |
|
|||
|
Coder Droid wrote:
> I decided to run some code with errors set to E_ALL, just to see what I > would run across. It caught a few things, but 90% or better of the > messages were of the 'undefined' kind: > > PHP Notice: Undefined variable > PHP Notice: Undefined index > PHP Notice: Undefined property > > I'd like to go back and fix what I can, but I'm wondering: how good or > bad is this? I mean, I rely on the fact that the first use of a variable > defines it. However, I'm also very used to "use strict" in perl, so I > know that on-the-fly variable declarations can be dangerous. > > Is there a general rule of thumb for correcting these? Best practice? Do > most people not care? If it ain't broke don't fix it? You won't get "undefined variable" etc if you do an assignment, but you will get the error if you try to reference it if it hasn't yet been assigned. For example, if this is the first line in your file, you'll get an "undefined variable" error message (although if you had register globals on a foo was passed in the query string then you'd be ok, but that's bad practise anyway): print $foo; It's a good idea to code with notices on when you are in development as it helps you catch stuff like this out which may actually cause more problems than you realise. You'll get undefined index if referencing an array item which hasn't yet been defined eg print $foo['bar']; and undefined property when it an object property hasn't been assigned eg $foo = new foo(); print $foo->bar; class foo { // yes, it's empty! } However, due to the dynamic nature of PHP this extension of the above example is acceptable, even though the bar propert was not declared in the foo class: $foo = new foo(); $foo->bar = 1; -- Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/ |
|
|||
|
> For example, if this is the first line in your file, you'll get an
> "undefined variable" error message: > > print $foo; > But $foo will have a clean initial value, right? That is, it's not unpredicable garbage (like this was C or something...) So it really comes down to: did you mean to do this or not, it would seem. > It's a good idea to code with notices on when you are in development as it > helps you catch stuff like this out which may actually cause more problems > than you realise. That makes sense. If you get it down to ones you know about and are acceptable, you can move to production with a good sense that you don't have any loose ends: even things unit tests might not catch. Hmmm... --cd |
|
|||
|
Coder Droid wrote:
>> For example, if this is the first line in your file, you'll get an >> "undefined variable" error message: >> >> print $foo; >> > > But $foo will have a clean initial value, right? That is, it's not > unpredicable garbage (like this was C or something...) So it really > comes down to: did you mean to do this or not, it would seem. Yes, assuming register gloabals is OFF. But it's still better to assign it yourself. If register globals is ON it may very well have already been assigned a value eg with www.domain.com/?foo=1 then $foo will have already been set to 1 so you cannot trust the value. This is why they changed the default for register globals to OFF. -- Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/ |
|
|||
|
>> For example, if this is the first line in your file, you'll get an
>> "undefined variable" error message: >> >> print $foo; >> > >But $foo will have a clean initial value, right? That is, it's not Not if register_globals is on and someone found it useful (or malicious) to give $foo some other initial value. The message may also be a good way of catching that you really meant $food. >unpredicable garbage (like this was C or something...) So it really >comes down to: did you mean to do this or not, it would seem. > >> It's a good idea to code with notices on when you are in development >as it >> helps you catch stuff like this out which may actually cause more >problems >> than you realise. > >That makes sense. If you get it down to ones you know about and are >acceptable, you can move to production with a good sense that you don't >have any loose ends: even things unit tests might not catch. I say: leave the notices on in production, but send them to syslog. Users are ingenious in using stuff in ways the designer didn't expect. Scanning the logs occasionally for problems may help you find problems. Much of my PHP code makes heavy use of isset(), especially on variables expected to be imported from the HTTP request. It calls attention to issues such as: What happens if $_GET['email'] ISN'T set? It *CAN* happen, even if you have Javascript on your page to require it being filled in. Remember, anyone can get a copy of your page (as sent from the browser: this won't include the PHP, but it will include the Javascript if any), then edit it removing any input checks, and submit it. Also, anyone can telnet to the web server and make up any sort of HTTP request with manual typing that they want. Gordon L. Burditt |
|
|||
|
> I say: leave the notices on in production, but send them to syslog.
Hmmm.... that's an interesting idea. Although, I highly doubt I could do that in my shared hosting environment. But it has sparked an idea or two. > Users are ingenious in using stuff in ways the designer didn't expect. No kidding. I have a rudimentary shopping cart which every once in a while gets checked out with 0 items in the cart. I can NOT reproduce this behavior whatsoever. But they sure can from time to time! What's the old phrase? About how programmers are trying to make idiot-proof systems while the universe is producing better idiots...? --cd |