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

Freek Lijten:
Sane defaults over Exceptions
Jan 18, 2017 @ 10:19:13

In a new post to his site Free Litjen talks about defensive programming and the part that sane default handling plays when dealing with exceptions that might pop up.

With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations.

The post starts with a quote about defensive programming and how, despite it not being an ideal use, many applications had been seen using exceptions to handle errors and messaging. He proposes another methodology where a set of default values are used instead of just failing on any error hit with the input. The idea has merit but it can also lead to other frustrations like hidden errors in testing and situations where an exception makes more sense than a default.

tagged: sane default value exception error handling defensive programming

Link: http://www.freeklijten.nl/2017/01/04/Sane-defaults-over-Exceptions

Medium.com:
The Art of Defensive Programming
Dec 30, 2016 @ 12:59:38

In this post on Medium.com author Diego Mariani talks about the "Art of Defensive Programming" as it relates to the security of the code developers write.

Why don’t developers write secure code ? We’re not talking yet another time about “clean code” here. We’re talking about something more, on a pure practical perspective, software’s safety and security. Yes, because an insecure software is pretty much useless.

[...] Why do I think Defensive Programming is a good approach to issue these problems in certain kind of projects? [...] I personally believe this approach [of continued functionality even in unforeseen circumstances] to be suitable when you’re dealing with a big, long-lived project where many people are involved. Also for instance, with an open source project that requires a lot of extensive maintenance.

He then covers some of what he sees as key tenets of programming defensively:

  • Never trust user input
  • Use database abstraction
  • Don’t reinvent the wheel
  • Don’t trust developers
  • Write SOLID code
  • Write tests

For each item in the list he provides a brief summary of the idea behind it and, in some places, some example code to help illustrate the point. The examples are in PHP but the principles could be applied to just about any language.

tagged: defensive programming tutorial security tenets

Link: https://medium.com/web-engineering-vox/the-art-of-defensive-programming-6789a9743ed4#.u3bzu5xam

Full Stack Radio:
37: Chris Hartjes - Getting Started with Testing
Mar 09, 2016 @ 13:22:10

The Full Stack Radio podcast has posted their latest episode, Episode #37, featuring an interview with Chris Hartjes, most well known for his promotion and teaching about writing tests (unit, functional, integration, etc) for your applications.

n this episode, Adam talks to the Grumpy Programmer himself about getting started with testing PHP applications.

Topics include: recommended testing tools, PHPUnit vs. phpspec, Mockery vs. Prophecy, the benefits of defensive programming and how to convince your manager to let you write tests.

They also mention Chris' new book "Minimum Viable Tests" and the Patchwork monkey patching library. You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the episode directly. Be sure to subscribe to their feed or follow them on Twitter for more information as new episodes are released.

tagged: fullstackradio chrishartjes testing gettingstarted tools defensive programming manager

Link: http://www.fullstackradio.com/37

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: