Book Review: IPhone Applications Tune-up

Packt recently published a new book- IPhone Applications Tune-up. The book is of course about programming for the iPhone. But there is one chapter on maintainability that is far broader applicability than just the iPhone. This review was written by Wes Boudville.

Moses explains several general aspects of programming that can and should be adhered to by most participants. Experienced programmers already know this. But if you are starting professional coding, you should pay serious heed. Specifically Moses says you should comment your source code. However, it is "likely a developer's least exercised skill".

Learn to regularly put into the source code intelligent comments that explain the context of the source lines they are next to. Especially if the source is intricate. Moses disposes of the objection that some say, that the time taken to write comments could be more profitably spent writing more code. This is blissfully and conceitedly wrong. It ignores the reality that code can be wrong in the first place. Then if you are the hapless programmer tasked to debug, trying to discern the intent in someone else's long ago written code that totally lacked line or block comments, can be grim and slow. Imagine "reading through a thousand lines of source code trying to figure out exactly what it was you or someone else was trying to accomplish". That is not a figure of speech when source code for a commercial package can now span well over 100 000 lines. And million line legacy packages are scarcely unknown.

The practical reality is that code has to be maintained. The supposed saving in not writing comments is lost later. What Moses omits is the extra nudge to the programmer. Chances are, if you add good comments, the person who you will be helping later is you. Even in large teams, the reality can be that if you wrote some code in the first place, and you are still at the company later, you will be the one to debug it. Comment for your own sake. It is a sign of experience.

Something else Moses might have said, but did not. Try to comment immediately after you have written the code, or perhaps just before. The latter is done by some who write the comments as the framework and then flesh it out with code. You should refrain from having a discrete block of time, days after you write code, where you go back and insert comments. Your short term memory is at its best when used immediately. Commenting later increases the risk that the comments are wrong or omit important details.

In the chapter, Moses also warns of library bloat. Sounds familiar? Where people have gleefully stuffed a grab bag of myriad routines into not just one library file, but several. It bloats up the final size of your executable, because of unnecessary routines that just got dragged in as collateral damage. Plus, you get a tangle of libraries, with interdependencies that become all to apparent when you have to update 1 library, and get a spaghetti ripple of others.

Moses also praises refactoring. Some programmers despise it. But there can be a sense of accomplishment that helps motivate you. More tangibly, refactoring can improve the performance, if you find speedups in core loops. An immediate gain. Also maintainability might improve when you learn more about the deep structures of the code. The literal case where you pull out or make subroutines that are used in several places makes the source code more robust. No code duplication.

To buy this book please visit: Here