Agreed, any formatting that is decided on should be initially applied in a single commit to the entire code base to prevent a two line commit from turning into 300 lines of changes listed in the commit log, and everyone should always format their code before committing, preferably on-save actions.
-omar On Thu, Jan 5, 2012 at 1:34 AM, Iwo Banaś <banas....@gmail.com> wrote: > 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" <rol...@stackandheap.com> 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 <omarg.develo...@gmail.com> > 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 <aha...@adobe.com> wrote: > > > > > > > Go for it. > > > > > > > > > > > > On 1/4/12 2:13 PM, "Michael Schmalle" <m...@teotigraphix.com> 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 <roge...@rogeliocastillo.com>: > > > > > > > > > >> maybe a pre-commit hook into svn client that run the formatter > just > > > > >> before the commit happens would work. > > > > >> > > > > >> --- > > > > >> Rogelio Castillo Aqueveque > > > > >> roge...@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 <dart...@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=Prefere > > > > >>>> nces > > > > >>>> > > > > >>>> > > > > >>>> - Doug > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: Michael Schmalle [mailto:m...@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 | rol...@stackandheap.com | > > http://www.stackandheap.com > > >
