One of the best things about PHP is that it is a great language to just 'dive into'. Thanks to its wide-ranging popularity, anyone with the ability to hit "Search" on Google can quickly create a program. However, this also lends to a major criticism of PHP, i.e. it is almost too easy to find and reproduce bad code.
Here are some mistakes that any PHP programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but unfortunately, they can trip up even the best PHP programmer! Other mistakes are hard to spot (even with strict error reporting). However, all these mistakes have one thing in common: They are easy to avoid.!
Single quotes, double quotes
It's easy to just use double quotes when concatenating strings because it parses everything neatly without having to deal with escaping characters and using dot values. However, using single quotes has considerable performance gains, as it requires less processing.
Consider this string:
[code]
$boo = 'everyone';
$foo = 'hello $boo';
$bar = "hello $boo";
[/code]
$foo outputs to "hello $boo" and $bar gives us "hello everyone". That's one less step that PHP has to process. It's a small change that can make significant gains in the performance of the code.
NOT Using database caching
If you use a database in your PHP application, it is strongly advised that you at least use some sort of database caching. Memcached has emerged as the most poplar caching system, with mammoth sites like Facebook endorsing the software.
Memcached is free and can provide very significant gains to your software. If your PHP is going into production, it is strongly advised to use the caching system.
Not Using E_ALL Reporting
Error reporting is a very handy feature in PHP, and if you're not already using it, you should really turn it on. Error reporting takes much of the guesswork out of debugging code, and speeds up your overall development time.
While many PHP programmers may use error reporting, many aren't utilizing the full extent of error reporting. E_ALL is a very strict type of error reporting, and using it ensures that even the smallest error is reported. (That's a good thing if you're wanting to write great code.)
When you're done developing your program, be sure to turn off your reporting, as your users probably won't want to see a bunch of error messages on pages that otherwise appear fine. (Even with the E_ALL error reporting on they hopefully won't see any errors anyway, but mistakes do happen.)
Not Escaping Entities
Many times PHP programmers are too trusting with data, especially data generated by user. It's imperative to sanitize data before it goes into any sort of storage, like a database.
Source Rally shows us how to correctly escape entities in things like forms. Instead of using this:
echo $_GET['username'];
You can validate the data by using htmlspecialchars() (or htmlentities()) like so:
echo htmlspecialchars($_GET['username'], ENT_QUOTES);
Using Wrong Comparison Operators
While comparison operators are an extremely basic part PHP programming, mixing these up in your code is certain to bork your program. As the German proverb states, the devil is in the details!
Being familiar with the often-misused operators like =, ==, != , are absolutely critical to PHP programming. Taking the time to really understand the differences will greatly speed up your programming and yield less bugs to debug.
Not using PDO
Don’t get me wrong, mysqli is (quite literally) generations ahead of the ancient mysql extension. It’s kept up to date, secure, reliable and fast. However, it’s mysql specific. Using PDO instead would let you use some wonderfully practical object oriented syntax, and would prepare you for tango with other SQL databases like PostgreSQL, MS SQL, and more. What’s more, PDO will let you use named parameters, a feature so useful, few people can imagine going to anything else after having taken proper advantage of it.
Last but not least, there’s this: you can inject fetched data directly into a new object, which is a delightful timesaver in large projects.
Not rewriting URLs
Another commonly ignored and easy to fix issue. URLs like mypage.com/index.php?p=43&g=24 are just not acceptable in this day and age. Due to it being incredibly difficult to write a good URL rewriting guide that would cover every server and framework out there, almost every framework has a guide on how to set up clean URLs (Laravel, Phalcon, Symfony, Zend) and any that don’t just aren’t worth using – they obviously don’t care about modern practices.
Not optimizing your queries
99% of PHP performance problems will be caused by the database, and a single bad SQL query can play havoc with your web application. MySQL’s EXPLAIN statement, the Query Profiler, and many other tools can help you find that rogue SELECT.
Using * in SELECT queries
Never use * to return all columns in a table–it's lazy. You should only extract the data you need. Even if you require every field, your tables will inevitably change.
Under or over-indexing
As a general rule of thumb, indexes should be applied to any column named in the WHERE clause of a SELECT query.
For example, assume we have a usertable with a numeric ID (the primary key) and an email address. During log on, MySQL must locate the correct ID by searching for an email. With an index, MySQL can use a fast search algorithm to locate the email almost instantly. Without an index, MySQL must check every record in sequence until the address is found.
It is tempting to add indexes to every column, however, they are regenerated during every table INSERT or UPDATE. That can hit performance; only add indexes when necessary.
Here are some mistakes that any PHP programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but unfortunately, they can trip up even the best PHP programmer! Other mistakes are hard to spot (even with strict error reporting). However, all these mistakes have one thing in common: They are easy to avoid.!
Single quotes, double quotes
It's easy to just use double quotes when concatenating strings because it parses everything neatly without having to deal with escaping characters and using dot values. However, using single quotes has considerable performance gains, as it requires less processing.
Consider this string:
[code]
$boo = 'everyone';
$foo = 'hello $boo';
$bar = "hello $boo";
[/code]
$foo outputs to "hello $boo" and $bar gives us "hello everyone". That's one less step that PHP has to process. It's a small change that can make significant gains in the performance of the code.
NOT Using database caching
If you use a database in your PHP application, it is strongly advised that you at least use some sort of database caching. Memcached has emerged as the most poplar caching system, with mammoth sites like Facebook endorsing the software.
Memcached is free and can provide very significant gains to your software. If your PHP is going into production, it is strongly advised to use the caching system.
Not Using E_ALL Reporting
Error reporting is a very handy feature in PHP, and if you're not already using it, you should really turn it on. Error reporting takes much of the guesswork out of debugging code, and speeds up your overall development time.
While many PHP programmers may use error reporting, many aren't utilizing the full extent of error reporting. E_ALL is a very strict type of error reporting, and using it ensures that even the smallest error is reported. (That's a good thing if you're wanting to write great code.)
When you're done developing your program, be sure to turn off your reporting, as your users probably won't want to see a bunch of error messages on pages that otherwise appear fine. (Even with the E_ALL error reporting on they hopefully won't see any errors anyway, but mistakes do happen.)
Not Escaping Entities
Many times PHP programmers are too trusting with data, especially data generated by user. It's imperative to sanitize data before it goes into any sort of storage, like a database.
Source Rally shows us how to correctly escape entities in things like forms. Instead of using this:
echo $_GET['username'];
You can validate the data by using htmlspecialchars() (or htmlentities()) like so:
echo htmlspecialchars($_GET['username'], ENT_QUOTES);
Using Wrong Comparison Operators
While comparison operators are an extremely basic part PHP programming, mixing these up in your code is certain to bork your program. As the German proverb states, the devil is in the details!
Being familiar with the often-misused operators like =, ==, != , are absolutely critical to PHP programming. Taking the time to really understand the differences will greatly speed up your programming and yield less bugs to debug.
Not using PDO
Don’t get me wrong, mysqli is (quite literally) generations ahead of the ancient mysql extension. It’s kept up to date, secure, reliable and fast. However, it’s mysql specific. Using PDO instead would let you use some wonderfully practical object oriented syntax, and would prepare you for tango with other SQL databases like PostgreSQL, MS SQL, and more. What’s more, PDO will let you use named parameters, a feature so useful, few people can imagine going to anything else after having taken proper advantage of it.
Last but not least, there’s this: you can inject fetched data directly into a new object, which is a delightful timesaver in large projects.
Not rewriting URLs
Another commonly ignored and easy to fix issue. URLs like mypage.com/index.php?p=43&g=24 are just not acceptable in this day and age. Due to it being incredibly difficult to write a good URL rewriting guide that would cover every server and framework out there, almost every framework has a guide on how to set up clean URLs (Laravel, Phalcon, Symfony, Zend) and any that don’t just aren’t worth using – they obviously don’t care about modern practices.
Not optimizing your queries
99% of PHP performance problems will be caused by the database, and a single bad SQL query can play havoc with your web application. MySQL’s EXPLAIN statement, the Query Profiler, and many other tools can help you find that rogue SELECT.
Using * in SELECT queries
Never use * to return all columns in a table–it's lazy. You should only extract the data you need. Even if you require every field, your tables will inevitably change.
Under or over-indexing
As a general rule of thumb, indexes should be applied to any column named in the WHERE clause of a SELECT query.
For example, assume we have a usertable with a numeric ID (the primary key) and an email address. During log on, MySQL must locate the correct ID by searching for an email. With an index, MySQL can use a fast search algorithm to locate the email almost instantly. Without an index, MySQL must check every record in sequence until the address is found.
It is tempting to add indexes to every column, however, they are regenerated during every table INSERT or UPDATE. That can hit performance; only add indexes when necessary.
Forgetting to back up
It may be rare, but databases fail. Hard disks can stop. Servers can explode. Web hosts can go bankrupt. Losing your MySQL data is catastrophic, so ensure you have automated backups or replication in place.
Some key points related to basic php development...
ReplyDeleteI would like to know aboutDB caching(memcache) coz its somthing that i would like to learn