On 27.05.2008, at 17:33, Bert Freudenberg wrote:
I'm not implying this is the case for SwaLint, but, there are cases where started-from-scratch alternatives take away resources that would have been better spent improving an existing implementation.
In many ways it is better to spent time on improving existing software, however let me mention a few things concerning SwaLint:
It was a student project which aimed at "improving Smalllint" or providing a tool which integrates Smalllints capabilities.
The main goals of the project were to produce a software which has - An intuitive UI - Support for metrics - Support for test configurations - The above mentioned Smalllint integration
We spent a lot of time in analysing Smalllint and its architecture in order to find out whether it is feasible to extend it. We found out, that it would lead to a major architectural change to make Smalllint capable of reusing results from other tests (which is a definitive must if you want to provide metrics support). As well it has no support for test configurations and an unintuitive UI (that is just my opinion). Therefore we created our own tool.
Smalllint is a great tool for the sophisticated developer. Our tool however is also intended to be usable for the normal programmer. "Select your classes and tests on one screen, click, and here is a very good structured overview over the problems in your application. (Maybe do some configuration)."
That is why we will definitely not support scoping in such a way as Smalllint allows it. Also, we will not support refactorings. However it takes about 5 minutes to integrate new Smalllint-Tests in our program (the tests written by Lukas for Seaside-applications are already in the development build of SwaLint).
Those are then - "easy to use" - integrated into a cool UI. Accessible for everybody even the guy who does not care about AST, scoped environment browser and so on.
Maybe usability is the kind of "selling arg" even if it does not appeal to everybody.
Have a nice week, Nico