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

SitePoint PHP Blog:
More Tips for Defensive Programming in PHP
Jan 25, 2016 @ 12:07:48

The SitePoint PHP blog has posted a tutorial continuing on from some previous advice with even more defensive programming practices you can use in your PHP applications.

Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. [...] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?

They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on - "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):

  • Input validation
  • Preventing Accidental Assignment in Comparisons
  • Dealing with Try/Catch and Exceptions
  • Transactions

They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it's not to the determent of the overall user experience or sharing messages with users that may just confuse them.

tagged: tutorial series defensive programming tips failfast input validation assignment trycatch transaction

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

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: