18/04/2009

Working Standards

well, i've now been working at yell adworks for almost three months, and i'm really enjoying it so far. after spending (probably too much) time on design, we have got started on development of a workflow engine system. i'm using spring, hibernate, mule, cxf, jbpm and other interesting technologies, some of which i'm still learning about (mule and associated esb technologies) or, in the case of spring, updating myself on - until now the most recent version of spring i had used was 2.0.9 and we are using 2.5.6, with attendant annotation based goodness and so on.

one of the only problems so far is the continuous integration system, which is set up with a very strict set of checkstyle and PMD rules for code quality. i'm all in favour of managing code quality as an automated process and continuous integration with these tools is a Good Thing, but i keep falling foul of some of the rules, in particular the checks for multiple return statements in one method, to enforce single exit points. i believe writing methods with guard clauses up front is the most readable and elegant way of expressing certain types of logic, and apparently martin fowler agrees (see his refactoring book) with me. the following discussion on stackoverflow is relevant, too. also, there are strict rules on long variable names, which keep me from naming things like constraintDefinition or workflowInstance although i do agree with the restriction on short (less than four characters) names.

i'm (really) going to try and make more of an effort to keep this blog updated more frequently, since it's over a year since i last posted ;)