Perl coding and saving your time.

At the start of 2008 and over the past two months we have been writing and re-vising code and being pleased to find it easier than often it can be. In this post we just wanted to explain why it has been so easy and why it matters to people coming to us looking to get work done.

The coding work we have been doing recently is revising a perl based application to meet changes in the way people want to use it. As with many applications in businesses, the application started as something entirely different and in this case it started life in a different programming language and was migrated by someone (not by us) and eventually became a piece of software being used by users. It has expanded beyond being a “quick hack”, to being used in production.

When we looked at the project of revising the code earlier this year we made it clear that step one would be to implement some coding style conventions and start moving to a test driven development model. This did mean that initially we were spending chargeable time simply tidying the existing codebase and not making changes or adding the changes the client required. We were fortunate that we conveyed the importance of doing this to the client and they agreed to paying for the work.

So what did we do and why is it worth doing?

Obviously, we can’t give too much away, but what we can share is below.

We decided that we would automate as much of the stylistic testing as possible and also that we would start by writing tests to confirm operation of the application (and the code). We also wanted to test the known bugs. What this meant is we took some time writing code that would test not only that things worked correctly but also that tested for known bugs and in effect proved that parts of the code failed.

What we did was start from the outside and work our way in, as opposed to “unit testing” first. We worked this way because we wanted to quickly establish a starting point with ‘x‘ tests that passed and ‘y‘ tests that failed BEFORE we touched the code in any way! We then worte tests for specific modules within the code and added them to a metrics. Again, this was before we touched the original source code provided to us at all! This was important to us and the client to establish that we were not making the code worse.

Once we had some basic testing in place that confirmed things worked as we understood them and showed up the known bugs; we moved into touching the original source code for the first time and started reformatting it. We started by running the code through Perl::Tidy each and everytime we ran the test suite. Perl::Tidy is a great tool and helps ensure we all follow a style (in our case we chose to follow the http://www.perl.com/doc/manual/html/pod/perlstyle.html guidelines ). By using Perl:Tidy as part of the test suite, we help ensure that the team don’t get lazy and start leaving messy code about.

At this stage we also started documenting the code both in external documents and also within the code itself.

Next we added Perl::Critic to our test suite. Perl::Critic is another useful tool as it programmatically allowed us to test that the code followed some “Perl Best Practices” specifically those from Damian Conway’s seminal book on best practices for Perl coding. Now, all developers have opinions on what is and is not good practice, and we can disagree and alter the policies. But as a general rule we like to use the policies as they come “out of the box” as the standards are well documented and it is a starting point that all levels of developer can use as a base.

Running Perl::Critic was when the first batch of real alterations to the code started. We started changing the code till we reached compliance of the first 3 levels of Perl::Critic errors quite quickly and then we stopped for a moment. At this stage we had a codebase that looked substantially different but performed exactly the same in terms of functionality and bugs.

So next we looked at the bugs and altered the code to resolve the bugs, by which we meant that we considered that a bug was fixed when the test we had written initially had passed, that no other tests had started failing, and that Perl::Critic had no new errors. We also added quite a few tests at this point to test specifics of the code we were adding (approximately doubling the number of tests in the suite). At this stage we were happy that we had made some improvements to stability of the code and this was when we rolled up a version number and passed the code back to the client for approval.

Why do all that work at the start?

You may be sitting there thinking “why did they waste all that time and not just fix the bugs right away?“. Other than professional pride, we went through the extra steps because it is making our job easier day on day. So as we reach a point in the process where we want to add more complex and sophisticated changes to the software, we have a test suite that proves that we have not broken the software with any new changes. The standards help ensure that as people move around the codebase it has a consistent look, feel and way of doing things.

This is particularly helpful for us as we are sending iterations of the code back to the client, it can take weeks to get the approval that they like the code and that they want us to start on the next change to the software. These breaks have the effect that we may not look at the code for a couple of weeks, having good tests and standards means that we are already comfortable with the layout and styles in the code when we return to it. We know right away if we have broken something inadvertantly as well. This means that each time we start a new alteration we spend less time on it than we would if we had not established the stylistic standards and tests.

This in turn means that we spend less time on making changes and that doing them is easier/safer from our perspective, so we don’t need to charge our clients as much for the work. It also has the advantage that the work can efficiently and effective be done in small bundles, which make sit easier to manage for both us and for the clients. Small monthly bills as opposed to large bills at the end of some months of work.

What it means to you? (or why are you posting this online?)

The reason we are sharing this online is so that someone trying to decide between us and another company has a reason to choose us. We genuinely believe that by using standards and tests we produce better work and produce it faster. This means that when we quote for work, we can be both the better quality AND lower cost option.

For “you”, it means that be it a web site, a web application or some other work, you now have an understanding of some of our philosophies in regard to using coding standards. It means that we think it means a better service for you and that we want to share it with you as we feel strongly that it is an important factor you will want to consider when comparing vendors.

“Nasty Bug” image by Nils Pickert on Flickr.