Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

SitePoint PHP Blog:
Defensive Programming in PHP
Jul 21, 2015 @ 11:49:07

In an article from the SitePoint PHP blog author Jeff Smith walks us through some advice he has about defensive programming in PHP, that is good practices for writing code that more gracefully handles potential error points.

Defensive programming, simply put, is programming with the intent to anticipate likely failure points. The goal is to circumvent those likely problems before they occur. You see the problem, right? There’s something inherently difficult with the advice “expect the unexpected” and it’s made many times worse when one alters it to “expect the unexpected and try to prevent it”. Let’s look at some practical examples.

He touches on a few of the most common places where errors could be introduced with unexpected input or functionality:

  • Conditional Statements
  • User Input (and trusting it....hint: never)
  • Assumptions [Made] About Your Code
  • Tunnel Vision (or not using good development practices)
  • Consistency in Syntax and Naming

Each point in the list includes a brief summary of what to look out for and things you can do to prevent the problem. It's by no means an exhaustive list, but it is a good place to start.

tagged: defensive programming tutorial opinion advice

Link: http://www.sitepoint.com/defensive-programming-in-php/

PHPClasses.org:
8 defensive programming best practices to prevent breaking your sites
Apr 26, 2007 @ 11:11:00

As anyone who's been developing applications (web or otherwise) knows, there are certain things that you just don't do when you're doing things like adding features or changing the code of a production application. There are some general rules to follow and this new article on the PHPClasses.org website reminds us of just a few.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

  • Handle unexpected conditions Test your code
  • Monitor your site errors and act upon them
  • Do not disclose errors to the users
  • Do what you can as you can never get defensive enough
He also recommends two resources for some additional reading - the Wikipedia entry for "defensive programming" and a chapter from Getting Real (from 37 Signals) about how to "Get Defensive".

tagged: defensive bestpractices break site defensive bestpractices break site

Link:

PHPClasses.org:
8 defensive programming best practices to prevent breaking your sites
Apr 26, 2007 @ 11:11:00

As anyone who's been developing applications (web or otherwise) knows, there are certain things that you just don't do when you're doing things like adding features or changing the code of a production application. There are some general rules to follow and this new article on the PHPClasses.org website reminds us of just a few.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

  • Handle unexpected conditions Test your code
  • Monitor your site errors and act upon them
  • Do not disclose errors to the users
  • Do what you can as you can never get defensive enough
He also recommends two resources for some additional reading - the Wikipedia entry for "defensive programming" and a chapter from Getting Real (from 37 Signals) about how to "Get Defensive".

tagged: defensive bestpractices break site defensive bestpractices break site

Link:

Ivo Jansch's Blog:
Defensive Programming
Jan 27, 2006 @ 07:01:48

In his latest blog post today, Ivo Jansch takes a look a t a situation where a little "defensive programming" would have helped.

A few weeks ago, we had a major problem with software we'd written for a client. It was software for sending mailings to the client's customers. Suddenly there were many reports of clients receiving multiple mailings instead of just one.

The problem appeared to be in our test code. The software had a 'test' mode for testing the mailing by sending it only to the author and a small test team. It appeared that for some reason, all test mails were being mailed to the customers as well.

This problem would not have appeared if we had applied what I would like to call 'defensive programming'.

He shows code examples from this situation, pointing out where the issue lies - a bad check in an if() statement.

tagged: defensive programming error situation defensive programming error situation

Link:

Ivo Jansch's Blog:
Defensive Programming
Jan 27, 2006 @ 07:01:48

In his latest blog post today, Ivo Jansch takes a look a t a situation where a little "defensive programming" would have helped.

A few weeks ago, we had a major problem with software we'd written for a client. It was software for sending mailings to the client's customers. Suddenly there were many reports of clients receiving multiple mailings instead of just one.

The problem appeared to be in our test code. The software had a 'test' mode for testing the mailing by sending it only to the author and a small test team. It appeared that for some reason, all test mails were being mailed to the customers as well.

This problem would not have appeared if we had applied what I would like to call 'defensive programming'.

He shows code examples from this situation, pointing out where the issue lies - a bad check in an if() statement.

tagged: defensive programming error situation defensive programming error situation

Link: