Fool me once, shame on you; fool me twice, shame on me
Ensuring mistakes aren't repeated is a commonplace activity for any development team. This can manifest itself in many ways such as writing regression tests, stepping up your code reviews, adding stories to a testing plan or humiliating the developer in question through use of an unusual (dunce's) hat.
We had an issue recently where some debugging code got committed and wasn't picked up during testing. Naturally, this code was picked up once it hit the production environment, we put rapidly put a patch in place. An embarrassing moment but the kind of thing that happens from time to time down in the trenches.
One possible remedy for this would be to add a new sniff to the in-house coding standard (which is tested using the PEAR code sniffer on a SVN pre-commit hook) to look for debugging code and block the commit if any is found. However, a quicker solution was to modify our deployment scripts to search the codebase and bail out if any debug code was found. We use phing as our deployment tool - here's the appropriate section from our build file:
<echo msg="Checking codebase for use of var_dump()" />
<exec command="[ `find ${folder.app.export}/classes -name '*.php' | xargs grep -nr '\(^\s*|\s\+\)var_dump(.*\?);' | wc -l` -eq 0 ]" dir="." checkreturn="true" />
The command here is grepping all PHP files within the SVN export for occurrences of var_dump. If any such matching lines are found then a non-zero exit will be returned and the build will fail. We haven't had such an issue since.
From "Javascript: the good parts":
It is rarely possible for standards comittees to remove imperfections from a language because doing so would cause the breakdage of all of the bad programs that depend on those bad parts. They are usually powerless to do anything except heap more features on top of the existing pile of imperfections.
Douglas Crockford's terse yet lucid javascript primer makes some excellent points on writing in a language with more than its fair of share of shortcomings. The advice is manyfold: constituting functionality or design decisions to avoid (the "bad" and "awful" parts) as well as patterns and practices making use of the strongest parts of the language. Essentially, one is guided to programming within a subset of the language, avoiding the poor quality and outright dangerous components. This chimes in well with the notation of "programming into a language" rather than within in it - stressed by the seminal "Code Complete" by Steve McConnell.
Don't limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal.
Both these concepts are relevant to programmers of PHP - a language carrying just as much baggage as javascript. In my experience, developers who have only known PHP are prone to employing of a variety of bad practices and anti-patterns. Such things are fostered by several influences, including the forgiving nature of the language, the veritable wealth of bad advice within the comments on the PHP manual, and a general lack of understanding of the art of object-oriented programming. Indeed, I think it's essential that PHP developers learn to program (and hence think) in other languages: python and java in particular. Reading the work of Martin Fowler is a good place to start but that's a topic for another time.