Posted by: junal on: November 5, 2007
Use one config file: well, I had this bad experience recently. I was assigned to a project which was done by row php and I was supposed to fix the bugs of the project. So I got the project and installed in my laptop. This is where main problem begun when I started changing configuration files!! I gave up after changing 16 config files! How come you can use individual config file?? You gotta keep one config file for the whole project. But you don’t have to worry about it if you’re using a php framework.
You should develop something that other developer can read it easily and understand easily.
Keep “Error reporting” on: Sometimes you see a blank page without any error. You are probably thinking what the hell is wrong with your code???
If you want to make your testing phase easy then you gotta work keeping your Error reporting on. Personally I found it’s really helpful, hence you know exactly what’s going on the project and where you made the mistake. You can use different kinds of error reporting options but I recommend you to use this below error reporting function at the top of your php page.
error_reporting(E_ALL);
or
ini_set('error_reporting', E_ALL);
Use print_r() :
I found it’s really helpful to see actually what is going on with your variable/array. If you are not familiar with this function let me give you a definition from PHP manual:
“print_r() displays information about a variable in a way that’s readable by humans. If given a string, integer or float, the value itself will be printed. If given an array, values will be presented in a format that shows keys and elements.”
Let say you have an array like this
$a = array (‘a’ => ‘apple’, ‘b’ => ‘banana’, ‘c’ => array (‘x’, ‘y’, ‘z’));
Ptint_r($a) will certainly print your array but let me give you a tips to see your array nicely organized. Use HTML tag <Pre> before you print your array. So example will be like bellow:
<pre>
<?php
$a = array (‘a’ => ‘apple’, ‘b’ => ‘banana’, ‘c’ => array (‘x’, ‘y’, ‘z’));
print_r ($a);
?>
</pre>
And output will be like this:
Array
(
[a] => apple
[b] => banana
[c] => Array
(
[0] => x
[1] => y
[2] => z
)
)
You can also use var_export(), and var_dump() for similar reason. And well, this is more helpful when you work on a developed application. Certainly you don’t know all data process that was developed by other devs. Print_r() helps you to recognize all values that are passing through your current page.
Use manual: I saw many PHP developers who don’t use PHP manual. To me its kind of strange thing! How come you don’t use the best Manual in the world!? I have never seen a Manual so organized and fulfilled like PHP manual. What you want from there? It’s always better to learn by yourself and in that case none but PHP manual is your best friend. Just download the latest version of PHP manual if you are using PHP 5 and start reading from the beginning. I can bet you will love it even if you are not a PHP developer.
Use long tag: Both short tag and long tag being used extensively. But your webhost must enable the short tag (<? =) in php.ini to make it run. To make your application safe you better use long tag (<?php echo “”)
Separate your HTML part: You may include HTML parts that you reuse across pages like the navigation, header, footer etc. I guess, instead of coping and pasting same code for similar pages you better make a separate file for them and later you just can add them in your page according to the need.
Make your application location independent: I got this experience recently from my foreign project. Your local directory and my local directory might not be same. And when you up the project in the real server that’s also not same right. So you must try to make your directory configuration independent.
Let me give you an example:
$absolute_path = ‘D:\xampp\htdocs\yadda\gadda; //assign changing part in a variable
require_once(“$absolute_path /lib/something.php “); //then just use it like this. So that next time you don’t have to change each line instead you just have to make change on one line. It’s similar like keeping one config file instead of several.
PHP coding standard: Try to follow a PHP common standard so that life becomes easier for other developers. You may follow your own style of coding but you have to keep it in mind that you’re not the last developer for the project you’re working on. Make sure new people can get what you have meant with your code. Make sure programmers can go into any code and figure out what’s going on. To do so you must wrote your code following a standard and common PHP coding. To get some clear idea please some goggling.
Use a framework: uhm…ya of course this is a part of good practice. Once you have general idea about PHP you can move to a PHP framework and that should be MVC patter follower (i.e. CakePHP and CodeIGniter). If you use a framework, most of the problem I mentioned above will be solved! Built-in functionality will make your life easier I can tell you.
Well that’s all from me. I know I have missed a lot of good practices here. All I have written from my little experience with PHP. Please feel free to suggest me more good practices for PHP developers.
Joining one or more php groups form where one can get help and also can help others, reading RSS feed form different php site is a good practise for a php developer i thnik.
Hi,
I’d add in:
1) Use some sort of logging mechanism; never ‘echo’ stuff out – as you may always leave something behind! See e.g. Zend_Log, PEAR::Log etc. Adapting the logging class to print class/file name and line numbers is a great help.
2) Develop a thin, internal API, which makes things ’safe by default’ – e.g. wrap access to $_POST, $_GET etc in a function (e.g. postGet()) which can handle sanitisation; and if you use something like Smarty, override the ‘assign()’ method so by default it sanitises data going into the template layer.
3) Use prepared statements, or a ORM; this (should) remove any chance of SQL injection.
4) Use a templating layer, and make sure that by default (with no effort from yourself) it can sanitise output (i.e. htmlentities($x, ENT_QUOTES)); otherwise you’ll eventually have an XSS hole.
David.
November 10, 2007 at 11:07 am
“You gotta keep one config file for the whole project.” + ” But you don’t have to worry about it if you’re using a php framework. ”
I can’t agree with you. CakePHP that needs almost no configuration, has 6 config files. Amongst them 3 are often used – core/routes/database
IMPOV, There is no point of keeping one single config file, it may create more confusions. Rather create separate config files for serving individual purposes, give them meaningful names, write comments with examples inside the config files (look at any CakePHP config file).
That’s all!