Building Quality into Scala Development

The argument and debates regarding writing quality code have mostly rested in the favour of writing clean code. Cleanliness fosters quality. Clean code is straightforward, direct, reads like a story and makes it very understandable.

As a rule that we have at Knoldus, if your code does not read like a story and we have to interrupt in between to understand wtf is going around then it is bad code. Period.

If you are coming from the Java world like most of us and if you have been writing beautiful code in Java unlike most of us 😉 then you would realize that there is a lot of tooling in Java which we end up missing in Scala. This tooling helps us keep honest. It helps us ensure that the code that we write is worth every minute spent on it.

The first lesson that needs to be remembered is that the code is SOLID compliant. It should follow the Single Responsibility principle, should be open for extension and closed for modification, should be Liskov substitution principle compliant, should follow Interface Segregation Principle and should follow Dependency Inversion so that it is dependent on abstractions and not concretions. More on SOLID with Scala here.

Once we know that the design is good, let us see what tooling which is available in Scala helps us do a good job.

Code Coverage – This would help us know the quality of our test cases. OK, there is a debate that 100% code coverage does not mean anything but let this argument not demotivate you. There is a lot of goodness in writing effective test cases and you realize this more and more as your product grows. Jacoco and SCCT are your friends here. The post on Jacoco and SCCT would guide you on how to incorporate these into your product.

Acceptance Tests – Any functionality that we write should be adequately covered by acceptance tests. There are quite a few posts in our acceptance test series which would help you with tooling like Fitnesse, ScalaTest, Cucumber etc. We have also written some compelling test scenarios with ScalaTest and Selenium. A further icing on the cake is to run them headless with phantomjs. Post coming soon on how to use it with your Lift and Play projects.

Code Quality – We have mentioned that code which can be read and understood by humans (computers are patient enough to read all the crap that we write) is of the best kind. ScalaStyle (getting nostalgic about CheckStyle?) is a great help here. It comes with 48 (and growing) tests which help us keep a tab on the quality of our code. We did not get the eclipse plug-in to work for us but the command line works like a charm and is our constant companion.

Copy Paste Detection – The biggest evil that has been consuming productive hours since ages has been duplicate code. A recent addition to our tool-kit has been CPD for sbt. It allows us to make sure that there are no unwanted duplications of code. The results are very promising. There is soon going to be a post on how to use it in your Lift project.

Findbugs – One of the superheroes from the Java world has been findbugs. This is another tool from the stack of jmhofer. We are yet to graduate this one into our daily toolset but the comments show that it does report quite a few false positives. Our initial tests show that the results are not that bad.

Are you using any other tools to make sure that your scala code is upto the mark? Drop a few lines in comments and we would definitely want to try them out.