This is likely not an option due to lexical errors, a lot of
formatters out there aren't perfect since they parse and re-emit code.
If there was a formatter that was written that hooked into the flex
compiler's AST, that is another animal.
I would love to work on that. :)
Mike
Quoting Rogelio Castillo Aqueveque <rogelio@rogeliocastillo.com>:
> maybe a pre-commit hook into svn client that run the formatter just
> before the commit happens would work.
>
> ---
> Rogelio Castillo Aqueveque
> rogelio@rogeliocastillo.com
>
>
>
>
> On 4/01/2012, at 6:57 PM, Michael Schmalle wrote:
>
>> This is kind of what I was getting at.
>>
>> The problem with the Flex Formatter is it's an Eclipse plugin that
>> last time I looked. The dev might have abstracted it but I don't
>> know.
>>
>> The problem is Flash Builder is not the only ide in town.
>>
>> Mike
>>
>>
>> Quoting Douglas Arthur <darthur@vmware.com>:
>>
>>> I for one vote that we suggest developers to use FlexFormatter and
>>> publish a settings file for public consumption. I believe Adobe
>>> uses it in-house, please someone correct me if I'm wrong? And I
>>> even believe there's a settings file floating around from Adobe.
>>>
>>> http://sourceforge.net/apps/mediawiki/flexformatter/index.php?title=Preferences
>>>
>>>
>>> - Doug
>>>
>>> -----Original Message-----
>>> From: Michael Schmalle [mailto:mike@teotigraphix.com]
>>> Sent: Wednesday, January 04, 2012 2:48 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Flex SDK code conventions
>>>
>>> I hate this topic but it needs to be asked to the community.
>>>
>>> Since I am an initial committer I will stand by whatever the
>>> consensus is with the code I commit.
>>>
>>> But then the question, what are we doing about this?
>>>
>>> There is already ALOT of code in the sdk that uses different
>>> conventions. I think this is ridiculous because it slows down
>>> development switching from this format to that format (reading and
>>> writing).
>>>
>>> I don't have an opinion on conventions, just proposing there needs
>>> to be protocol with committers on this sooner than later. And this
>>> protocol needs to be documented on a public page visible to any
>>> one that has this same question creating patches.
>>>
>>> Mike
>>>
>>>
>>
>>
>>
>
>
|