incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rogelio Castillo Aqueveque <roge...@rogeliocastillo.com>
Subject Re: Flex SDK code conventions
Date Wed, 04 Jan 2012 22:08:22 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message