incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: Tooling ( Flex SDK code conventions )
Date Fri, 06 Jan 2012 17:22:05 GMT
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 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message