18 Critical Oversights in Web Development

Over the past years I had the opportunity to work on some interesting projects, complex in nature with an ongoing development, constantly upgrading, refactoring and adding new features to them.

This article will cover the biggest coding oversights most PHP developers make, when dealing with medium and large projects. Oversights such as not differentiating between development environments or not implementing caching and backup.

The examples below are in PHP, but the idea behind each problem is generic.

The root of these problems lies mainly in developers’ knowledge and experience, especially the lack of it. I’m not trying to bash anybody, I do not consider myself the perfect developer who knows everything, so bear with me.

In my experience we could categorize these problems in three main groups: design level, application level and database level oversights. We’ll break down each one separately.

Application Level Oversights

Developing with error reporting off

The only question I can ask is: why? Why do you not turn error reporting on when developing an application?

PHP has many levels of error reporting, and it ALL should be turned on in the development phase.

If you think errors will never occur, you are coding for the ideal scenario, which only happens in an ideal world.

Error reporting and displaying those errors are not the same either. error_reporting() sets the level of errors (e.g. notice, warnings, fatal errors) and display_errors controls whether these errors will be outputted or not.

Error reporting should always be at the highest setting in development: error_reporting(E_ALL); and ini_set('display_errors', true);

Note: E_ALL is the highest since PHP 5.4+, because E_STRICT errors became part of E_ALL in PHP 5.4. If you use an older PHP version than 5.4 use error_reporting(E_ALL | E_STRICT); to include strict error warnings too.

Continue reading %18 Critical Oversights in Web Development%

more