Almost Code Complete

It is my belief that every good developer must have read or is reading or atleast intends to read Steve McConnell’s Code Complete. The book essentially is considered to be a bible for software developers. For those focusing more on the coding part of software construction process, reading from Chapter 6 onwards makes sense. I have tried to select some important points out of the chapters focused on coding aspects. Although the whole book is made of important points I just want to underline some key thoughts to take away.

  • A class is a collection of data and routines that share a cohesive, well-defined responsibility.
  • Tap into the power or being able to work in the problem domain rather than at the low-level implementation domain.
  • Abstraction is the ability to view a complex operation in a simplified form.
  • Each class should implement one and only one abstract data type. If a class implements more than one type or you can’t figure out what ADT a class implements then reorganize  that class into more organized classes.
  • When you design a class, check each public routine if there is a need for its complement.
  • Each interface consists of a programmatic part and a semantic part. Programmatic part consists of the data types and other attributes of interface that can be enforced by compiler, semantic part contains assumptions about how the interface will be used which cannot be enforced by compiler. Look for ways to convert semantic interface elements to programmatic interface elements using Asserts or other techniques.
  • Don’t put a routine into a public interface just because it uses only public routines.
  • Code is read far more times than it is written even during initial development.
  • To avoid tight coupling, make data private in base classes rather than protected.
  • Be critical of classes containing more than about seven data members.
  • Follow the Liskov Substitution Principle, which in simple words state that, all the routines defined in the base class should mean the same thing when used in each of it’s derived classes.
  • Minimize indirect routine calls, if a object A instantiates an object B, then a routine in A can call routines on object B but should not call any routines of objects provided in object B.
  • For better readability, put the parameters in an input modify output order. List the parameters in input only, input and output, and output only order.
  • Don’t use routine parameters as working variables, store it in a local copy and use that for modification.
  • Use error handling code for conditions you expect to occur, use assertions for conditions that should never occur.
  • Use access routines instead of global data. It just makes it easy to modify them at a single place.
  • Don’t dump all the global data at a single place. Make sure that information hiding and ADT are maintained, which might result into global data stored into their meaningful classes.
  • Don’t make up phony variables to be used for a case statement. Since they are confusing, use if then statements instead.
  • If you have a loop, put any initialization required by the loop just before the loop to make it more readable.
  • Loop should follow the rule of a routine, they must perform one and only one function. Its better to break a loop into two to perform unrelated things.
  • It is bad practice to use the last value of an index of a loop in the code after the loop. Never assume that a loop will be executed until it’s last step.
  • The fact that a design uses inheritance and polymorphism does not make it a good design. Table driven methods sometimes can produce elegant solutions instead.
  • Use terms named true and false to check boolean value, using 0 and 1 makes code confusing in some cases.

An Interview with Thoughtworks

Recently I had been in a job search mode, got interviewed by Thoughtworks and Microsoft(when I was in US). I was keen in focusing on the “fundu” companies if you know what I mean. Lots of people know how Microsoft Seattle interview process goes, I would certainly like to belabor on Thoughtworks India process. I would say it was a fascinating experience where I learnt quite a few things like test driven development, pair programming and no cubicle culture. Also it did refreshed my old school problem solving techniques, white boarding etc.

So it all started by receiving an email from an HR person about an opportunity at Thoughtworks. Since I already followed Martin Fowler’s blog I knew quite a bit about them. They set up a informal like conversation with a HR person that week. We discussed a lot about what I do, I want to do, about my blog, projects on my resume. It was really a conversation about me marketing myself and the HR person doing his part for Thoughtworks. It went for about one and half hour which ended with he asking about my salary expectations.

After about 2-3 days I got a call from the same person explaining me the next step. He sent me an email which consisted of 2 problem statements Mars Rover problem and Sales Tax problem. You could certainly find these statements by surfing on the net. Here is a link to the sales tax statement I found I chose the Mars Rover problem just thinking it was more interesting to solve. It is important to that this stage really decides many things about your onsite interview. They do not just need a working solution, anyone could write one in less than an hour. What makes a good solution is how well the objects are designed, the naming convention and an overall decent to good OOPS knowledge implementation. I mean how well encapsulated your objects are, do you program too much to the implementation rather than to an interface, is your solution extensible because in an onsite interview you would be asked to extend this solution with a more complex requirement. I would suggest you to get a design patterns book just to improve the object design strategy in your solution, I do not say that design patterns must be used but they do help in achieving good object oriented code most of the times :).

After this, I got a call in 3-4 days for an onsite interview in their Pune office. The office, as I expected after reading few blogs, was different than my earlier offices. No cubicles, just one big room with round tables surrounded by chairs, people working on their laptops, a ping pong table at one side and nice lunch room. It was a really innovative idea to have such an office structure. I reached there a little early and I asked for restroom just to get my bearings! I asked a person working there,whether the restroom had cubicles atleast, thank god he took it lightly. The onsite process was designed as follows –:

- A self assessment test – 50 super easy questions in 12 minutes. These consists question like Miner and Minor, are they 1) same meaning, 2) contradictory, 3) Neither.

- A logic test – 11 flowchart questions in 1 hour 15 min. These problems are like following a flowchart, executing the instruction at each step and writing a final output. You just need utter concentration for this one but its fun.

These tests are by no means show stoppers, I think everyone gets through these unless you are really dumb. So no worries until now.

- Pair programming – Here a well seasoned person for Thoughtworks would pair with you and go about refactoring your code submission. This has to be an interactive session where we have to put our own ideas in improving the design and that person would do his part. Make sure you think about some improvements in your design if possible before getting in this stage. You should not be really adamant on your idea if you have any about solving some issue, pair programming is about good interactive programming. At the same time you should not be too submissive and agree to everything for obvious reasons.

- 1st technical interview – This involves 2 Thoughtworkers interviewing you at the same time. There would be discussion about technical expertise you possess, for me lots of questions on .NET were asked. I had to white board some of them to explain some code. There is OOPS design problem to be solved, here they see your capability of creating a decent high level design on the fly within the time span given. The problem could be something like design a video store library application or something on those lines. I kinda screwed up during this stage, my solution for the problem was not really good as far as I know. White boards do make me uncomfortable sometimes :) This interview lasted for like more than 1 and half hour.

- 2nd technical interview – This is a similar interview like the earlier one. I guess its another chance to see if a candidate can show better performance this time. By the way I left my home in Mumbai at 6 in morning and it was 7 in the evening for this interview. I was fucked up pretty much talking all day but I did experience such a day with Microsoft too. There is nothing really different to talk about this interview since it basically is targeted again on OOPS concepts and some problem solving techniques like creating a XOR gate from AND and OR gate.

So that was my experience and I guess it resonates with any other person who went until the final stage. I think it was a good experience knowing a different culture in the software field. Also to be honest it did help me to improve my coding skills by coding for some fun problem statement and getting it reviewed by a coding ninja, getting their insight on improving the design. So let me know if any of you guys need any more “up close” insight on the interview process.

Best of Luck!

RSS Reader using NSXMLParser

I was working on building a slick RSS reader for my iphone since last week. As you might guess, the core problem in building an RSS reader is to create a way to read the XML feed data. For a newcomer, this might sound straigtforward but once they rub nose with it, it would soon be clear that the various forms of feeds that are available now, makes it a tricky task. Above that, iPhone does not support the good guys of XML world, namely NSXMLDocument etc. This class in the Cocoa framework is really helpful with its XPath support to parse XML feeds easily. The NSXMLParser is the sole fighter in the XML arena on the iPhone device (as far as I know). Some folks have tried building wrapper classes to support iPhone, an example is TouchXML which is available at The class used by this method is CXMLDocument which is kinda on the same lines of NXMLDocument, but with much lesser support for parsing. It turned out that it was not good enough for what I needed to do.

So… I wrote a NSXMLParser! Now lets be honest here, not many people are lovers of Event driven xml programming and I am no exception. It just seems really tedious to take care of all the conditions in such a model when used for parsing. Enough bashing, here is some code to show how it can be used to parse an XML feed at a url.

- (NSMutableArray *)parseXMLFeedAtURL:(NSURL *)URL parseError:(NSError **)error 
channelFlag = NO;
mainTitleFlag = 0;
itemFlag = 0;
linkFlag = 0;
feedFlag = NO;
entryFlag = 0;
appDel = (iBlogReaderAppDelegate *)[[UIApplication sharedApplication] delegate];
NSXMLParser *parser = [[NSXMLParser alloc] initWithContentsOfURL:URL];
// Set self as the delegate of the parser so that it will receive the parser delegate methods callbacks.
[parser setDelegate:self];
// Depending on the XML document you're parsing, you may want to enable these features of NSXMLParser.
[parser setShouldProcessNamespaces:NO];
[parser setShouldReportNamespacePrefixes:NO];
[parser setShouldResolveExternalEntities:NO];
[parser parse];
NSError *parseError = [parser parserError];
if (parseError && error) {
*error = parseError;
[parser release];
return tempArray;

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict 
if (qName) {
elementName = qName;
if([elementName isEqualToString:@"channel"])
// Seems like a normal RSS feed.
channelFlag = YES;

// More code here.


- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName 
if([elementName isEqualToString:@"feed"] || [elementName isEqualToString:@"rss"] )
[parser abortParsing];

// More code here.


- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string 
if(tempArray != nil)
if(charString == nil)
charString = [[NSMutableString alloc] init];
if(mainTitleFlag == 1 || linkFlag == 1)
[charString appendString:string];

The above function acceps a NSURL object which is created using a url string and a pointer to pointer to an NSError object. To use NSXMLParser, the best thing would be to create a new NSObject class. In that class add the above methods so that this implementation stays away from your other application code. NSXMLParser needs didStartElement, didEndElement and foundCharacters methods to read values within elements. More methods are available if you refer to the reference library provided by Apple.

Every time a new tag is encountered, the didStartElement event is triggered, when it ends didEndElement is triggered, and when characters are found between tags the foundCharacters event is triggered. So you see the main issue is here to maintain the flow across events. It is very common to have nested “title” elements in an RSS feed, so care must be taken while parsing them. I use flags to check if certain element has been encountered by the parser or not. Well this method may vary according to your needs. In my app, I support both Atom and RSS feeds so I had to give option for the user to select which feed they need to subscribe to. Below is a snap of that view.

Picture 1

On Done, I loop through the selection list and parse each feed using my parser. Now the way I got these three feeds is by parsing the url entered in the textbox. It would be something like

<link rel="alternate" type="application/rss+xml" title="RSS" href="" />

I would like to share my XCode project if anyone needs it, although I am not sure where can I upload those files. But that can be figured out later. Let me know if you need any help is using the infamous NSXMLParser :).

Happy Programming!


RSS Reader for iPhone

If you have read my blog description just below the blog title you would realize where I am hanging out these days. [object message] is a way to send a message (method) to an object in objective C. I have been working on iphone sdk for a week, going through the online reference library at and stumbling over blogs explaining some code. Let me tell you, this week was full of new learning in terms of a language, a framework and frustrations! Here are a few snapshots of an RSS reader I built for the iphone.

Picture 8 Picture 1Picture 2 Picture 3

Picture 4 Picture 6 Picture 7 Picture 5

Before I delve into the major discussion about the app, let me frustrate those guys who are just entering the world of iphone development. In the XCode editor, which is used for writiing apps on Mac, there are 2 options to debug an application. One is in the iPhone Simulator whose snapshots are seen above. This is available to everyone who installs the iphone sdk. Other option is directly on the device, iPhone or iTouch. Hold On… You can debug and install apps created on an iphone ONLY IF YOU ARE A REGISTERED IPHONE DEVELOPER PAYING $99 TO APPLE EVERY YEAR. smirks!!! The account used for downloading the sdk is not the one used here. You will notice this when you would try to build the application and install it on your iPhone/iTouch and get an error saying something like Unable to Verify device 0X160434fuc@##$#shi#$#$ :), I learnt the hard way, if you want to know more about this mess read the blog post by Ralf Rottman here.

Anyways, if you are done pulling your hair off, here are some functionalities of the Reader –:

- Add and Remove a feed. The feed data gets stored in a property list which are basically a nice way to store application data.

- A refresh button causes s refresh of all blogs and displays the first post of each of them on the first screen.

- Read the post in a browser window itself. This is done using the UIWebVIew class which allows to open a url in a Safari browser window.

Another word of caution for guys trying to build something which would need to parse XML. The NSXML library which is the one used to parse XML in Mac applications does not work on the iphone/itouch but works on the simulator! I have not personally checked this but there are lots of blogs talking about it. So instead I used TouchXML which is an open source library on More information about how to use the parser in this library is well explained on Dean’s blog Some good references for beginners are here –:

1) Aaron Hillegas book on Cocoa Programming for MacOSX. – This is an awesome book for guys like me who have been working on Windows platform for a while and want to shift gears for some time and get some Cocoa! The book really helps a lot to make us understand several aspects of the Cocoa framework and Objective C. For ebook lovers, there is an online version of this book somewhere in the cloud, I have it, just search for it.

2) Apple has provided extensive coding how to’s and other references which I found helpful.

3) has good tutorials.

The iPhone sdk uses the MVC pattern, so its a good idea to follow that while building our apps.Create a separate View and View Controller for each different screen you wish to see in your app. If you righr click on the project in the left had side tree view panel of XCode you would see an option to add a Group. Click that and add a UIView and a UIViewController in it. This way you just have a clean separaion of all the files. When you create a project like a Utility Application Project or a Navigation project etc you would see some groups already created. So in short, an iPhone/iTouch app at one time displays a single View added as a subview to the main window. To change the screen, remove the view already there and add a new one. Thats how any application on iPhone/iTouch works.Since I use property lists to store the feed data, it becomes really easy to read and write to them. But do not use these lists if you expect the data to grow too much. Property lists are good for few hundred bytes. They are just XML format files which can be added to a project.

I will be posting some code snippets in my subsequent posts since its the code that matters! By this time in a week time or so I have pretty decent understanding on how the View Controllers, Views and other elements of an iPhone application interact with each other. Ill be talking a bit about using UINavigationControllers, sharing data among views and other important things which are used more often. Please let me know if you have any questions, Ill be glad to help.

Happy Programming!