Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1EFA391FE for ; Thu, 5 Jan 2012 09:35:07 +0000 (UTC) Received: (qmail 60657 invoked by uid 500); 5 Jan 2012 09:35:07 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 60542 invoked by uid 500); 5 Jan 2012 09:35:02 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 60516 invoked by uid 99); 5 Jan 2012 09:35:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 09:35:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of banas.iwo@gmail.com designates 209.85.215.175 as permitted sender) Received: from [209.85.215.175] (HELO mail-ey0-f175.google.com) (209.85.215.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 09:34:58 +0000 Received: by eaal1 with SMTP id l1so205641eaa.6 for ; Thu, 05 Jan 2012 01:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bEy1P5dHLxdC1lTGqcxZb8gjDqHldMe+Ri1MTaqZD14=; b=VgnlifpzA8hqH1zURu6v6SmWoUW6Ia68P5QKII56O+26R770Ax02v/5QB7qXAqiYG1 AfZsDVVcLcDIQZzvFUbiCunIp2DKhbQMf+K+XDt65C+1Ngtr65kqAXbKucXFb47+XHuQ J7n5WF2fVytvIe1hVjvCri8R2NlX9fkPLTrn0= MIME-Version: 1.0 Received: by 10.205.121.138 with SMTP id gc10mr511995bkc.3.1325756076521; Thu, 05 Jan 2012 01:34:36 -0800 (PST) Received: by 10.205.82.10 with HTTP; Thu, 5 Jan 2012 01:34:36 -0800 (PST) Received: by 10.205.82.10 with HTTP; Thu, 5 Jan 2012 01:34:36 -0800 (PST) In-Reply-To: References: <20120104171321.82151tjgbtatbk01@www.teotigraphix.com> Date: Thu, 5 Jan 2012 09:34:36 +0000 Message-ID: Subject: Re: Flex SDK code conventions From: =?UTF-8?Q?Iwo_Bana=C5=9B?= To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=00151740295cfff81304b5c4a35d --00151740295cfff81304b5c4a35d Content-Type: text/plain; charset=ISO-8859-1 Whatever formatting tool we use we should always make sure to separate reformatting from actual code change. It's a nightmare to review a 3 line bugfix when the patch contains 300 lines with formatting changes. When we agree on the codding standards and Adobe commits the code it would be worth to unify the formatting of whole code tree. That way it shouldn't be necessary to add any reformatting to subsequent commits. Cheers, Iwo Banas On Jan 5, 2012 9:21 AM, "Roland Zwaga" wrote: > I've worked on a project where IntelliJ and Flashbuilder with FlexFormatter > was used, it took a bit of tweaking > but both IntelliJ's formatter and FlexFormatter can be configured to > process files equally. > So config files for both IDE's can be created and distributed. Other IDE's > we'll need to look into of course. > > On 5 January 2012 08:33, Omar Gonzalez wrote: > > > I'm with the rest of the people that hold this as really important to > them. > > It makes it easier to read. I understand that we are not all going to > come > > to an agreement on 100% of the formatting, but that's what teams do, they > > come to a compromise and they all buy in and comply for the sake of the > > team. I think a solution like FlexFormatter is great, and we should look > to > > try and find solutions like it for other IDEs like IntelliJ and require > > that the settings files we come up with are used. Most of these tools > allow > > you to automatically format code as you save, I've used FlexFormatter > like > > that for a long time with our teams and it is great. It'll go a long way > > toward reading comfort. > > > > -omar > > > > On Wed, Jan 4, 2012 at 2:15 PM, Alex Harui wrote: > > > > > Go for it. > > > > > > > > > On 1/4/12 2:13 PM, "Michael Schmalle" wrote: > > > > > > > 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 : > > > > > > > >> 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 : > > > >>> > > > >>>> 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=Prefere > > > >>>> nces > > > >>>> > > > >>>> > > > >>>> - 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 > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > -- > > > Alex Harui > > > Flex SDK Team > > > Adobe Systems, Inc. > > > http://blogs.adobe.com/aharui > > > > > > > > > > > > -- > regards, > Roland > > -- > Roland Zwaga > Senior Consultant | Stack & Heap BVBA > > +32 (0)486 16 12 62 | roland@stackandheap.com | > http://www.stackandheap.com > --00151740295cfff81304b5c4a35d--