when i first started developing with php, i noticed that whenever a problem arose, 99% of the time it was because of a typo. but trying to spot that other 1% could be a pain. without the proper use of php’s built in debugging functions, you could easily debug your php problems in an instant.
having some sort of debugging system is especially important if you are putting together an OOP application or dashboard. having your users use your application and it fails on them without notice will frustrate anyone.
way one: notices
php has a wonderful thing installed into it’s language called notices. they made it for developers, so we should be using them. but what are notices?
a notice is a type of error message that you set. you can set it to either say “your code isn’t functioning properly” or “you are an idiot”. these are pretty useful since you have to set specific notices for specific functions in your code.
for example, if you are spitting out data from a database in an array, you can set it to fetch the array OR die with an error saying “you’re array fetch failed”.
now to make good use of notices, they must be turned on. to do this, just insert the following code in your project:
ini_set(‘error_reporting’, E_ALL);
now one thing you’ll notice is that every error you get will be echoed. for those of you who are not experienced with php, i will not teach you how to fix that. this will make you a better php developer if you figure things out for yourself. but those of you who are experienced developers should know that you should be using empty() and is_set(). they will be your new best friends.
way two: logging
logging is also a useful way to track bugs. you use logs usually when executing specific actions, such as writing records into a database or sending out an email. any and all errors, if present, will be logged once those actions execute. of course, if you know me, you know i’m a lazy developer. sometimes checking your log files can get tiring.
way three: checking your function params
sometimes you can create bugs even before your data is passed. sometimes these errors can destroy stored data, so be sure to check your function parameters if you have any.
way four: manual redirects
this is a redirect:
<?php
header(‘Location: some file.php’);
exit O;
?>
these can cause problems when debugging. i know when i first started making my first dynamic login pages, i had a problem with redirects and always mixed them up. you can be stuck in an infinite loop if you mix up your headers. so what can you do to avoid this? set a debug variable if the loop redirect fails.
here’s how you do that:
<?php
function redirect($url, $debug = false) {
if ($debug) {
echo “error message<br />\n”;
echo “Backtrace: <br /><pre>\n”;
debug_print_backtrace ();
echo “</pre>”;
} else {
header ( “Location: $url” );
}
exit ( 0 );
}
?>
way five: keep things simple, stupid
i’ve always been a firm believer in writing good clean code as well as structuring your syntax properly. i’d like to touch base in the future on php security based on syntax and structure. but basically, keeping things simple will also help you debug your code months later after your application is launched.
- keep an eye on functions that are growing too big.
- functions that are called in one place may be too specific. bring the code inline instead.
- watch out for functions with long names or too many arguments.
- use built-in functions instead of custom-built functions. most likely the built-in function will work better.
- documentation. create documentation for your users and developers. also create one for yourself.
conclusion
i just saved you hours of frustration and now i need to spend another 10 minutes trying to come up with some sort of clever closing? just take my stuff. develop on it. and next time, we’ll touch up on some php security based on your syntax and code structure.
Related posts: