In September 2008 I started working on a tool called AS3V. The goal of AS3V was to parse source code and to check the code against a set of rules. My main problem with the first attempt of AS3V was that I used ANTLR. ANTLR is a great tool to create a compiler but for ActionScript 3 and its various strange behaviours you have to do a lot of hacking. Parsing ActionScript, XML and regular expressions with the optional semicolon in ECMAScript is not really fun using such a tool. metaas went that path and unfortunately their parser fails very often.
This is the reason why I started writing a parser manually from scratch. But this is also not a good idea. What about Adobe changing the language or adding features? I would have to change my parser. This is for instance a problem you have with FDT. Adobe releases a feature and it will take a while until you can adopt that. Maybe that feature is only beta but you want to use it. So are you going to implement it or not? Since the Flex SDK is open source I decided to take a completly different approach. Option one is to modify the original ASC. I think this is a bad idea. On every update from the Adobe guys you would have to patch the compiler again, and release a compiled version of that. This is what flexcover does. But I do not want to replace core parts of the Flex SDK with a modified compiler. So this is the reason why AS3V links only against the ASC. This means basically I do not care about what Adobe does with the compiler as long as the API stays consistent. This means also AS3V knows only as much as the ASC. This is sometimes a problem but in most cases not so important. ASC drops for instance braces every time. AS3V does not know if you write if(true) trace('foo'); or if(true) { trace('foo'); }. But in the end AS3V is able to analyze the real compiler output which is huge; theoretically every implicit cast can be watched!
Now enough theory. Why bother using AS3V and what is it good for? Imagine a loop like this:
for( var y: int = 0; y < height; ++y )
for( var x: int = 0; x < width; ++x )
index = y * width + x;
AS3V is currently smart enough to analyze the statement y * width + x and to figure out that y and width do not change in the inner loop. AS3V is therefore able to warn you about unneccessary calculations. There are lot of other rules I have already implemented which help you writing better code. For instance the pattern if( expr0 ) { if( expr1 ) { foo(); } } can be reduced to if( expr0 && expr1 ) { foo(); }.
There is a lot of room for other rules. I am happy to see some progress and hope that other people will find AS3V as useful as I. In the current state I have to implement more rules and a little bit more complex ones like dead code detection with constant folding. A release is targeted once I am happy with the rule set.
Not to forget: An Eclipse plugin which will show you appropriate warnings as neat little icons is of course also planned.
In September 2008 I started working on a tool called AS3V. The goal of AS3V was to parse source code and to check the code against a set of rules. My main problem with the first attempt of AS3V was that I used ANTLR. ANTLR is a great tool to create a compiler but for ActionScript 3 and its various strange behaviours you have to do a lot of hacking. Parsing ActionScript, XML and regular expressions with the optional semicolon in ECMAScript is not really fun using such a tool. metaas went that path and unfortunately their parser fails very often.
This is the reason why I started writing a parser manually from scratch. But this is also not a good idea. What about Adobe changing the language or adding features? I would have to change my parser. This is for instance a problem you have with FDT. Adobe releases a feature and it will take a while until you can adopt that. Maybe that feature is only beta but you want to use it. So are you going to implement it or not? Since the Flex SDK is open source I decided to
