I could not find a CSV parser for Salesforce so implemented this one and decided to share it. It’s simple but it handles quotes, newlines and arbitrary delimiters (I’ve implemented a few CSV parsers over the years so hopefully I am getting the hang of it). One thing a bit special with this one is instead of “tokenizing” the string as one might usually do in an optimized parser I went with a regex approach, basically this means the string may have to get read twice in a worst case scenario, but the way Apex calculates the complexity of your code is essentially the number of statements that get run. So the higher level approach, even if they are a bit less efficient overall, score better with Apex (less likely to hit the governor limit).

Here is the associated test class. One thing I really dig about the SF development model is the integration with unit tests. This almost makes up for the suckiness of the IDE.

I might as well make a few comments about the development process. First of all, the unit test integration is rather nice. They will automatically “sandbox” your database for the unit test and give you a coverage report. A few things to watch out for:

• Keep your eye on the “Problems” tab. If there is an error, maybe in some other file, the IDE will still happily run the previous version of your tests and you’ll be left wondering why your changes are not taking effect. Happened to me more than once.
• Use a sandbox for development – very little can be done in a production environment because you need test coverage to deploy the code, and you can’t test the code until it’s deployed.
• The Force.com IDE sucks really, really bad. I don’t have anything against Eclipse – I love Eclipse for Java code! But writing Apex code is very, very primitive. The build operations are quite slow (not “SalesLogix App Architect” slow, mind you, but still slow) and the errors reported are not clear. Intellisense very rarely works. Stuff occasionally gets out of sync and has to be blown away and resynced from server. Also, only a few items can actually be done from the IDE, the rest has to be configured using the web interface which is very cluttered and confusing. The only redeeming factors are the documentation which is top notch (both the reference guide and the community) and the unit test integration.

An alternative to be aware of is that the processing can be done remotely and use the bulk update API to do the communication with the database. In retrospect it might have been the way to go in this scenario, since I already had to do some processing in a remote app, but this was a good project to tour the Apex facilities with so I am glad I got the chance to do that.

I also used Heroku for the remote processing part, this was my first non-toy app on that platform, and a very positive experience so far.