PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
Per the advice of some of the very helpful people in this forum, I've starting turning error_reporting(E_ALL) on during development. Here's one I get a lot:
Notice: Undefined index: title in /foo/bar/example.php on line 41
I've gotten into the habit of doing stuff like this:
So I was curious to know what kinds of standards some of the hotshots in this forum set for themselves. Do you make every notice go away before going live?
fgomez wrote:So I was curious to know what kinds of standards some of the hotshots in this forum set for themselves. Do you make every notice go away before going live?
Yes. Notices, warnings and errors show my clients that I'm a novice. Certainly I don't want to give such an appearance.
well I turn error reporting off in a production environment so that even if I am a novice my clients won't know about it... but just because I have become anal as hell (due to these forums mostly) I make sure there are no notices... good practice.
I have to agree with everyone here. It's usually not too hard to fix those types of errors (if it is hard to fix them, it's usually indicitive of a larger problem elsewhere), and I can't see any downside to spending the time to fix them.
Even if the errors don't show, they still fire. Errors firing slows down execution. If logging is on, they'll show in the error logs too, that's just as bad.
I think a correct answer to your question would be to focus less on what others do but to focus more on good and secure programming. This is mainly because if we're doing things wrong way you'll end up doing things wrong way. I think its more beneficial for you to know how to avoid common problems and avoid falling into security holes as opposed to patching the same.
You generally only ever need isset when dealing with passed parameters. Everything else should be initialized otherwise you open yourself up to global rewriting.
It is part of my standard to code to E_ALL as though error_reporting were on and register_globals is off. I always inititalize vars that are not asigned a value from somewhere else, I always use isset(), array_key_exists(), is_array(), etc. I refuse to have a client turn on display_errors and see something that I should have corrected. But that is me.
I only use isset() on external input (i.e. superglobals like $_POST, $_SERVER etc.) the rest are all pre-initialised with superceding comparisons against chosen default value.
Like others here before a site goes "live" I ensure all errors and notices are gone. In general I have it switched off by default, but I have a generic "debug class" which I can use (restricted to a specific user/IP Address) which switches the notices/errors on. The debug class also does other things such as displays the SQL calls/results, display the session variables as well as some timings, function call count and total timing for each function. When switched on it slows the page down but when switched off impact is minimal.
I am currently just changing the class to allow for the following $_GET['trace']==X where X is a combination of
1 - SQL Failures (SQL error, where found file, class, method, process_time).
2 - SQL Warnings (no results found, insert failed etc found, file, class, method, process_time).
4 - SQL Successful calls (file, class, method, process_time).
8 - $_SESSION (displayed as tree)
16 - $_POST
32 - $_GET
64 - $_COOKIE
128 - Method/Function Call Count/Timings (Sorted by Total Runtime per function)
256 - Method/Function Call Count/Timings (Sorted by Counter, how many times the function was run)
512 - Full Trace including arguments passed and timings (Again displayed as a tree).
So entering trace=139 would show all SQL Failures/Warnings, the SESSION variables and the methods/function calls sorted by the total run times for the method.