Mike,

Getting the formatter to run on the command line was an experiment... I really 
wasn't sure of the outcome - but I'm happy that it came together and with very 
little effort. My aim was to get familiar with prior art... I've been all 
through the Flex Formatter source and am now taking a look at jasblocks. Good 
stuff!

What am I proposing?

I'd like to create a tool that is able to generate a 'model' of an application 
- with an API that facilitates extension. What kind of extension?

Clean Code (e.g. formatters - to improve readability)

  # establish 'best-practice' code formatting / conventions
  # consistent formatting makes it a little less scary to bring new developers 
on-board
  # prevent rats-nest from new commiters ( big smiley face on this one )

Reduce Artifacts (reduce maintenance debt)

  # were there any un-used functions?
  # were there any un-used variables?
  # were meta-syntactic variables / methods / etc used? ( i.e. var foo:String, 
public function bar() )
  # were there any bits of code that were un-reachable?
  # were attachment points disrupted? ...if so - how much? (e.g. modification 
to public signatures, adding new, etc)

Performance (knowing how your application will perform before you deliver it)

  # what is the estimated footprint of the application?
  # what is the estimated number of instructions per method?
  # what is the estimated execution time per method? (a la Monocole)
  # were there any poorly performing blocks? (use a lexer to identify blocks 
that need improvement)

Testing / Acceptance

  # based on collected metrics - did a particular commit improve, degrade, or 
maintain?

I also have some thoughts on automation... but I think I need to stop (you 
probably get the idea - there is huge potential).

So... there are many tools out there - I'd say that maybe 60-ish percent of the 
above items are good-to-go. Getting to the next level is the hard part. Each of 
these tools duplicates code-scanning-bits and don't expose the model in an 
consumable/friendly way; extend or re-write is the question of the day. IMO, 
your documentation tool is a huge move in the right direction.

My next email is to Earnest. ;-)

Cheers,

Rick Winscot


On Thursday, January 5, 2012 at 5:18 PM, Michael Schmalle wrote:

> 
> Hi Rick,
> 
> > I'm looking at ANTLR3 now... and am entertaining a ground-up rewrite 
> > to get rid of unnecessary dependencies, improve performance, and 
> > flesh out some attachment points for other tooling (i.e. FlexPMD).
> > 
> 
> 
> What are you exactly proposing?
> 
> Have you though about contacting Ernest about any of this, I think 
> that is where you should start.
> 
> I'll say it's more complicated than it looks especially the way he 
> implemented the grammar. Depending on what you want to do it might be 
> hard for you to get a Tree out of what he has done.
> 
> I am pretty sure the way he implemented the grammar was not really 
> intended to much fiddling because of the backtracking.
> 
> I spent over a month studying that AS3.g :)
> 
> Let me know if you have any ideas, I already have a working AS3 
> parser/lexer in jasblocks antlr3, that if you really wanted to spend 
> time looking at grammar or modifying, it creates the AST Trees and 
> ALSO has an AS3 DOM already. The code target is java.
> 
> Check out;
> 
> https://github.com/teotigraphix/as3-commons-jasblocks
> 
> Look into the visitor package as well.
> 
> Mike
> 
> > That is essentially what I did - took all the dependencies and 
> > wrapped them up into a single executable jar. The final product is a 
> > little over 20mb - it would be great if we could shrink this down a 
> > bit.
> > 
> > Getting the formatter to run on the command line is a first step... 
> > unfortunately the only way to create the .properties file ( that 
> > drives the formatter ) is still in Eclipse. Next order of business 
> > should probably include creating a stand-alone piece for that.
> > 
> > I'm looking at ANTLR3 now... and am entertaining a ground-up rewrite 
> > to get rid of unnecessary dependencies, improve performance, and 
> > flesh out some attachment points for other tooling (i.e. FlexPMD).
> > 
> > Cheers,
> > 
> > Rick Winscot 

Reply via email to