incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <m...@teotigraphix.com>
Subject Re: Flex SDK code conventions
Date Wed, 04 Jan 2012 22:13:21 GMT
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
>>>
>>>
>>
>>
>>
>
>




Mime
View raw message