Most developers think that every “other” developer’s code is “no good.” In fact, it is exactly this “Not Invented Here” syndrome that makes it dangerous for other developers to evaluate an existing project’s quality without a checklist or template as a guide.
One of my coworkers, Scott, recently pointed me towards Jacob Kaplan-Moss’s comments on programming languages and thought. In “Syntactic Sugar”, Jacob addresses the canard that “all Turing complete language differ solely on syntactic sugar.” He first concedes that this is technically true, in terms of reduction to machine instructions and register manipulation. At the same time, he says, this view ignores the important effect qualitative differences in the syntactic structure of different programming languages have on the way we as programmers solve problems. In support of this, he introduces the Sapir-Whorf hypothesis from linguistics, which states that, rather than simply being a vehicle for thought, language in fact determines the limits of what is thinkable. He argues that this applies equally to programming languages, and concludes that “we’ll always be more productive in a language that promotes a type of thought with which we’re already familiar.”
One of the most important (and least loved) activities in a programmer’s life is debugging code. When debugging PHP, there are several strategies, ranging from strategic use of print_r to elaborate systems that send debugging information to specific debug tables in a database.
In this article, we look at a simple tip for finding errors in SQL code when using PEAR::DB.
This article, originally published in MacTech Magazine, gives tips on how to write your code such that retain count problems are easier to find and how to locate the problem when symptoms appear.