Thursday, December 29, 2011

Book Review - The Art of Readable Code by Dustin Boswell and Trevor Foucher; O'Reilly Media

Programmers Dustin Boswell and Trevor Foucher present The Art of Readable Code: Simple and Practical Techniques for Writing Better Code with the underlying premise that, "code should be easy to understand." This practical and clearly-articulated text provides sound advice to assist the reader with both fundamental and advanced techniques to write code which is easy to read and understand. With chapters organized into four progressively complex sections, Boswell and Foucher focus first on basic improvements to code, offering tips about naming, commenting, and aesthetics which are applicable to almost any code, both simple and advanced. Progressing to variables, loops, and logic and then to code reorganization into functions, the authors lead the reader through important lessons and a wealth of examples. The book culminates in a study of code testing and a case study analysis of code development, applying the principles offered in the preceding chapters.

This collection of solid programming advice is bolstered by numerous code examples in several mainstream programming languages, yet is presented at a level which is accessible to a broad audience. Whether a student needing guidance, a novice programmer, or a more experienced programmer who could use a reminder about good practices the reader is certain to glean valuable tips which will help him or her write better code. The authors are successful in creating an easy and fun read which can either be traversed cover to cover or selectively, with the help of the contents pages and index. Supplemented with expressive cartoons and quotations (including Yoda!), each chapter concludes with concise summaries which embody the key principles presented. A further reading list is also provided.

As a self-taught intermediate programmer, reading this book has helped me identify some areas in which I could make my existing code better. The authors draw attention to warning signs that code is not as easy to understand as it could be. I only wish that I had encountered this sage advice several years earlier before developing coding habits which need correcting. The success of Boswell and Foucher in their endeavor to educate programmers in the oft-overlooked area of creating code which is intuitive to the reader is evident to me because reading this book has caused me to reflect, learn, and resolve to write better code.

Practical, enjoyable, and very readable. Recommended for students in computer programming and any programmer, of any level of experience, who has looked back at his/her code of several months ago and thought, "What does this part do?"

O'Reilly Media provided me with a free electronic copy of this book. Learn more about The Art of Readable Code at http://oreilly.com

Wednesday, December 28, 2011

O'Reilly Blogger Review Program

Recently, I joined the O'Reilly Blogger Review Program. This innovative program allows ordinary people access to new texts and videos for the purpose of writing honest reviews and publishing them on personal blogs and consumer sites where the books are sold. I'm about to publish my first review. Interested? Learn more!

Thursday, December 22, 2011

Account for Every Possible Eventuality

I spent a day this week working on a project which needed some serious housekeeping doing to it. While working adequately for the end user, it was filling our PHP error log with volumes of warnings, primarily associated with referencing unset indexes or variables. In my earlier programming days I was good about accounting for events which I expected to happen in the logical flow through my code, but I often neglected to account for the unexpected. Some of my housekeeping included:

  • Always check that a variable is set if any possibility exists that it might not be, before trying to use it.
  • Declare the default  timezone when using server date/time variables. While it may assume correctly, it creates warnings to remind you to do so.
  • Don't pass empty variables to be processed by methods when it is unnecessary to do so.
  • Consider testing for NULL values and create procedures or breaks in loops for handling that.
It's common sense really, with hindsight, but when you don't know, you don't know. It's a case of live and learn. My appreciation of the usefulness of error logs has grown notably over the past year and that has caused me to lament all of the unnecessary warnings that I was causing. This is what spurred me into action and now my future projects will be all the more watertight.

Database Abstraction Switcharoo (2)

So I was continuing with my transition to PDO and I did encounter a rather annoying problem. When using MySQL Boolean or Natural Language searches, I couldn't get placeholders to work. Period. I tried everything I could think of and consulted numerous forums. Even put a question out there on stackoverflow.com but no answers in a week. I don't know if I'm overlooking something obvious, but I've been pretty thorough. I make sure my array has the exact amount of correctly-named variables and I reference each in the query only once. I get no useful error messages to give me even the first clue about what's giving it the grump. Grrrrrrrr.

Saturday, December 10, 2011

Database Abstraction Switcharoo

A database abstraction layer is a piece of software which helps to manage the interaction between a script, such as PHP, and a database, like MySQL. One of the advantages of such a tool is that it can help boost the security of interactions with the database, particularly when using user input from a web form to populate the database query. This introduces the danger of SQL injection, where a user tries to interact with the database inappropriately by writing SQL code in the form fields instead of the information the form is soliciting.

Another advantage of abstraction layers is that it is usually relatively easy to change the database back end on a project without having to substantially overhaul the code responsible for interacting with the database. Examples of abstraction layers include PEAR MDB2 and PDO. I was introduced to abstraction layers through MDB2, although recently I was forced to switch from MDB2 to PDO on a project when I changed the back end database to SQLite3. MDB2 couldn't interact with this iteration of SQLite.

This week I switched another project over to PDO even though the backend was remaining in MySQL. I was improving the security of my code by no longer passing completed SQL statements but instead assembling them using the abstraction layer and a technique using placeholders. However, I just couldn't get it to work in MDB2. It took offense when I used placeholders, named or unnamed. The error reporting pretty much told me nothing but it seemed as though the MDB2 connection was being lost or something like that. So in a short space of time I did the switcharoo to PDO and it worked like a charm.

Securely handling interactions between a script and a database, especially when user input is included, is an essential skill. It's well worth investing time in learning to utilize such a tool before you need to use it in a hurry.

Thursday, December 1, 2011

Structure and Forethought

A current project I'm working on, perhaps my biggest to date, is reminding me that it is very important to plan ahead for future scope when creating a code structure. In this case, I had big dreams but at the time didn't have the skills to put it all together. So I scaled down the project to the level at which I could cope. However, as time progressed and I developed new skills, I have been able to extend its scope to accomplish my original vision.

The consequence of scaling this project down was that the structure was scaled down also. Then, when I was able to add new elements to the project, I wound up overhauling the structure twice. This consumed a bit of time but served as an important lesson - If you anticipate a more complex structure than you might originally develop, design the project to be extensible so that it doesn't need a total restructure.

I'll spend a little more time in the future before diving in, to contemplate the potential complexity of a project rather than just the initial structure. This should result in more efficient code at the outset!