When Tutorials Attack
In a recent series of tutorials released by SUN Developers Community a few notable omissions glared back from the web page. Like many PHP tutorials that pollute the web, there was a little, or no error checking, or error handling in the provided code examples. These omissions are paramount to development in any language, particularly for those who's livelihood relies on the strength of perceived enterprise readiness of the technology. To the new comer, these tutorials are the source of truth, and quality code examples are required if these new comers are going to produce quality code.
The tutorial in question, brings to light the need for tutorial writers and PHP authors to provide not only the basics of the subject being presented, but also how to handle errors when things go wrong.
To the credit of the author, a disclaimer is provided siting "the sample code assumes that the user always provides well-formed input, hence there is no explicit error checking code". This is possibly the most common assumption that tutorial writers make when providing code examples. It assumes knowledge of programming practices such as input validation and error checking, yet promotes itself as a tutorial for beginners in such colorful terms as Application developers who are new to the development of MySQL database applications with PHP are the target audience of this article". These types of disclaimers almost read "My boss made me write this so I am not going to put any effort into it". Without so much as a link on where to find the missing information need to create quality code, the new comer is left use the only empirical source available, and that is the code in front of them.
Error handling cannot be shrugged off by saying "that is another topic unto itself". Error handling and security are the base model upon which applications need to be developed. For those entering PHP for the first time, it is never more important for them to see working, real life examples of how to deal with errors. Without this simple addition, new comers to PHP venture into the world and insecure applications and scripts proliferate with the end result being that PHP has not strength and is an insecure language. This need not be the case.
In a development environment, error handling is the tool by which developers can dictate program flow should errors occur. The use of die() should rarely be used, and never in a production environment. It can be a quick and effective tool during development to quickly spot errors, but when new comers see this in code examples, they do the natural thing, and copy the example. Who can blame them, particularly when the code is produced by a supposedly authoritative source, in this case SUN/MySQL.
The need for comprehensive examples is to promote all that is good with PHP, sure, not everybody is happy, but there are many robust applications developed with PHP that the world rarely hears of, because the overwhelming noise is coming from the nay- sayers touting examples of insecure code and thus perpetuating the myth that PHP is not an enterprise level language, when nothing could be further from the truth.
When this myth is perpetuated, the value of PHP is deflated, along with the worth of application developed with PHP, and application developers. It is a no win situation, that can be avoided by the simple addition of a few lines of code to ensure the graceful degradation of the script of application. Everybody who has an interest in PHP is getting less cash in the pocket due to the absence of a few lines of code.
How will new comers learn secure development practices from the provided examples? These new comers look to tutorial authors as the source of truth and hold them in esteem. It is not until later they become confident enough to challenge the truths portrayed in the tutorials and examples they have learned from. When they do put forward new and better ideas, then the work of the author has been successful, and everybody wins.
This article is not about bashing SUN/MySQL for the omissions in their particular endeavor, although, as an authoritative source one would expect more. It is about getting together as authors and promoting the language as it should be, rather than a few random lines of code that assume a knowledge of development that may not be within the users range at the time of reading.