Flex SDK code conventions

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Flex SDK code conventions

Michael Schmalle
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


Reply | Threaded
Open this post in threaded view
|

RE: Flex SDK code conventions

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=Preferences


- Doug

-----Original Message-----
From: Michael Schmalle [mailto:[hidden email]]
Sent: Wednesday, January 04, 2012 2:48 PM
To: [hidden email]
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


Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Carol Frampton
In reply to this post by Michael Schmalle
There is a coding standard but unfortunately not everyone chose to follow
it, or only followed the parts they liked.

http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

I am in favor of a coding standard.  I like uniform looking code.

Carol

-----Original Message-----
From: Michael Schmalle <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wed, 4 Jan 2012 13:48:25 -0800
To: "[hidden email]" <[hidden email]>
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
>


Reply | Threaded
Open this post in threaded view
|

RE: Flex SDK code conventions

Michael Schmalle
In reply to this post by Douglas Arthur
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 <[hidden email]>:

> 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:[hidden email]]
> Sent: Wednesday, January 04, 2012 2:48 PM
> To: [hidden email]
> 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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Jonathan Campos
In reply to this post by Carol Frampton
Carol, we talked about this previously. I am right there with you about
uniform code. Big deal to me.

On Wed, Jan 4, 2012 at 3:54 PM, Carol Frampton <[hidden email]> wrote:

> There is a coding standard but unfortunately not everyone chose to follow
> it, or only followed the parts they liked.
>
> http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
>
> I am in favor of a coding standard.  I like uniform looking code.
>
> Carol
>
> -----Original Message-----
> From: Michael Schmalle <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Wed, 4 Jan 2012 13:48:25 -0800
> To: "[hidden email]" <[hidden email]>
> 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
> >
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Fréderic Cox
In reply to this post by Carol Frampton
+1 , if it can be done with FlexFormatter it would be even better

On 04/01/12 22:54, "Carol Frampton" <[hidden email]> wrote:

>There is a coding standard but unfortunately not everyone chose to follow
>it, or only followed the parts they liked.
>
>http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
>
>I am in favor of a coding standard.  I like uniform looking code.
>
>Carol
>
>-----Original Message-----
>From: Michael Schmalle <[hidden email]>
>Reply-To: "[hidden email]" <[hidden email]>
>Date: Wed, 4 Jan 2012 13:48:25 -0800
>To: "[hidden email]" <[hidden email]>
>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
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Michael Schmalle
In reply to this post by Jonathan Campos
> http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

This is exactly why I asked because I saw that, what 4 years ago? :)  
Still committed code didn't follow it.

As committers, if we agree on a convention, to we have the right to  
turn down code that does not follow it and tell the developer to  
format it correctly?

Surely it's not our job to do this.

Mike


Quoting Jonathan Campos <[hidden email]>:

> Carol, we talked about this previously. I am right there with you about
> uniform code. Big deal to me.
>
> On Wed, Jan 4, 2012 at 3:54 PM, Carol Frampton <[hidden email]> wrote:
>
>> There is a coding standard but unfortunately not everyone chose to follow
>> it, or only followed the parts they liked.
>>
>> http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
>>
>> I am in favor of a coding standard.  I like uniform looking code.
>>
>> Carol
>>
>> -----Original Message-----
>> From: Michael Schmalle <[hidden email]>
>> Reply-To: "[hidden email]" <[hidden email]>
>> Date: Wed, 4 Jan 2012 13:48:25 -0800
>> To: "[hidden email]" <[hidden email]>
>> 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
>> >
>>
>>
>
>
> --
> Jonathan Campos
> Dallas Flex User Group Manager
> http://www.d-flex.org/
> blog: http://www.unitedmindset.com/jonbcampos
> twitter: http://www.twitter.com/jonbcampos
>




Reply | Threaded
Open this post in threaded view
|

RE: Flex SDK code conventions

Douglas Arthur
In reply to this post by Michael Schmalle
Fair enough. I hadn't considered other ide's. Maybe there are alternatives that could be setup for other ide's with supporting documentation of code guidance, rather than "standards". I agree we can't make everyone follow the same coding conventions, but we can highly encourage them.

>From my experience it's really hard to find multiple coders that completely agree on a convention, because everyone has their own. But if we can at least agree on a subset, and publish it into a guideline and/or some sort of formatting utility, then it's better for the collaborative efforts on large projects.

- Doug

-----Original Message-----
From: Michael Schmalle [mailto:[hidden email]]
Sent: Wednesday, January 04, 2012 2:57 PM
To: [hidden email]
Subject: RE: Flex SDK code conventions

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 <[hidden email]>:

> 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=Pr
> eferences
>
>
> - Doug
>
> -----Original Message-----
> From: Michael Schmalle [mailto:[hidden email]]
> Sent: Wednesday, January 04, 2012 2:48 PM
> To: [hidden email]
> 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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Rogelio Castillo Aqueveque
In reply to this post by Michael Schmalle
maybe a pre-commit hook into svn client that run the formatter just before the commit happens would work.

---
Rogelio Castillo Aqueveque
[hidden email]




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 <[hidden email]>:
>
>> 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:[hidden email]]
>> Sent: Wednesday, January 04, 2012 2:48 PM
>> To: [hidden email]
>> 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
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Jonathan Campos
as a committer you have the ability to 0/-1 code for formatting. I would
think it would be considered "polite" to let them know that was the reason
was formatting so they can do a quick fix.

On Wed, Jan 4, 2012 at 4:08 PM, Rogelio Castillo Aqueveque <
[hidden email]> wrote:

> maybe a pre-commit hook into svn client that run the formatter just before
> the commit happens would work.
>
> ---
> Rogelio Castillo Aqueveque
> [hidden email]
>
>
>
>
> 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 <[hidden email]>:
> >
> >> 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:[hidden email]]
> >> Sent: Wednesday, January 04, 2012 2:48 PM
> >> To: [hidden email]
> >> 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
> >>
> >>
> >
> >
> >
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Michael Schmalle
In reply to this post by Rogelio Castillo Aqueveque
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 <[hidden email]>:

> maybe a pre-commit hook into svn client that run the formatter just  
> before the commit happens would work.
>
> ---
> Rogelio Castillo Aqueveque
> [hidden email]
>
>
>
>
> 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 <[hidden email]>:
>>
>>> 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:[hidden email]]
>>> Sent: Wednesday, January 04, 2012 2:48 PM
>>> To: [hidden email]
>>> 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
>>>
>>>
>>
>>
>>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Alex Harui
Go for it.


On 1/4/12 2:13 PM, "Michael Schmalle" <[hidden email]> 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 <[hidden email]>:
>
>> maybe a pre-commit hook into svn client that run the formatter just
>> before the commit happens would work.
>>
>> ---
>> Rogelio Castillo Aqueveque
>> [hidden email]
>>
>>
>>
>>
>> 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 <[hidden email]>:
>>>
>>>> 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:[hidden email]]
>>>> Sent: Wednesday, January 04, 2012 2:48 PM
>>>> To: [hidden email]
>>>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Omar Gonzalez
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 <[hidden email]> wrote:

> Go for it.
>
>
> On 1/4/12 2:13 PM, "Michael Schmalle" <[hidden email]> 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 <[hidden email]>:
> >
> >> maybe a pre-commit hook into svn client that run the formatter just
> >> before the commit happens would work.
> >>
> >> ---
> >> Rogelio Castillo Aqueveque
> >> [hidden email]
> >>
> >>
> >>
> >>
> >> 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 <[hidden email]>:
> >>>
> >>>> 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:[hidden email]]
> >>>> Sent: Wednesday, January 04, 2012 2:48 PM
> >>>> To: [hidden email]
> >>>> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Roland Zwaga
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > Go for it.
> >
> >
> > On 1/4/12 2:13 PM, "Michael Schmalle" <[hidden email]> 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 <[hidden email]>:
> > >
> > >> maybe a pre-commit hook into svn client that run the formatter just
> > >> before the commit happens would work.
> > >>
> > >> ---
> > >> Rogelio Castillo Aqueveque
> > >> [hidden email]
> > >>
> > >>
> > >>
> > >>
> > >> 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 <[hidden email]>:
> > >>>
> > >>>> 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:[hidden email]]
> > >>>> Sent: Wednesday, January 04, 2012 2:48 PM
> > >>>> To: [hidden email]
> > >>>> 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 | [hidden email] | http://www.stackandheap.com
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Iwo Banaś
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> > > Go for it.
> > >
> > >
> > > On 1/4/12 2:13 PM, "Michael Schmalle" <[hidden email]> 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 <[hidden email]>:
> > > >
> > > >> maybe a pre-commit hook into svn client that run the formatter just
> > > >> before the commit happens would work.
> > > >>
> > > >> ---
> > > >> Rogelio Castillo Aqueveque
> > > >> [hidden email]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 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 <[hidden email]>:
> > > >>>
> > > >>>> 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:[hidden email]]
> > > >>>> Sent: Wednesday, January 04, 2012 2:48 PM
> > > >>>> To: [hidden email]
> > > >>>> 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 | [hidden email] |
> http://www.stackandheap.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Omar Gonzalez
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ś <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
> > >
> > > > Go for it.
> > > >
> > > >
> > > > On 1/4/12 2:13 PM, "Michael Schmalle" <[hidden email]> 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 <[hidden email]>:
> > > > >
> > > > >> maybe a pre-commit hook into svn client that run the formatter
> just
> > > > >> before the commit happens would work.
> > > > >>
> > > > >> ---
> > > > >> Rogelio Castillo Aqueveque
> > > > >> [hidden email]
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> 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 <[hidden email]>:
> > > > >>>
> > > > >>>> 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:[hidden email]]
> > > > >>>> Sent: Wednesday, January 04, 2012 2:48 PM
> > > > >>>> To: [hidden email]
> > > > >>>> 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 | [hidden email] |
> > http://www.stackandheap.com
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Raju Bitter
In reply to this post by Iwo Banaś
2012/1/5 Iwo Banaś <[hidden email]>:
> 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.
That would be excellent, if someone would be willing to do the extra work.

- Raju

Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Christophe Herreman
In reply to this post by Carol Frampton
2012/1/4 Carol Frampton <[hidden email]>

> There is a coding standard but unfortunately not everyone chose to follow
> it, or only followed the parts they liked.
>
> http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
>
> I am in favor of a coding standard.  I like uniform looking code.
>

+1 for the coding conventions.

Although I do want to point out that the coding conventions at
http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions are not
complete and there are a lot of "TBD"'s in the document.

We've been using a variant subset of these conventions (so much for coding
conventions) and made some changes that I think are worth being discussed.
For instance, repeating an accessor name in the block comment is cumbersome
when refactoring the accessor name as the documentation is not updated.
Although your IDE might do a code replace as well as a text replace, this
is not ideal as it will most likely change the text in unwanted places. IMO
it is better just to have a separator line (the first line of 40 chars)
above the accessor so you can visually distinguish between blocks of
accessors without repeating the accessor name.

Other changes are tabs instead of spaces, braces alignment and a few others.

If there is a discussion being set up to discuss and finish the document,
I'm willing to participate.

--
Christophe Herreman
http://www.herrodius.com
http://www.springactionscript.org
http://www.as3commons.org
Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Michael Schmalle

> We've been using a variant subset of these conventions (so much for coding
> conventions) and made some changes that I think are worth being discussed.
> For instance, repeating an accessor name in the block comment is cumbersome
> when refactoring the accessor name as the documentation is not updated.
> Although your IDE might do a code replace as well as a text replace, this
> is not ideal as it will most likely change the text in unwanted places. IMO
> it is better just to have a separator line (the first line of 40 chars)
> above the accessor so you can visually distinguish between blocks of
> accessors without repeating the accessor name.


+1 on this, although I kinda of favored it in say Flex 2, it's very  
depressing if I got out the calculator and figured out how much time I  
spent pasting those and updating them before we had code templates in  
IDEs. :)

Christophe is talking about

//--------------------------------
// fooBar
//--------------------------------

public function get fooBar():void
...

> Other changes are tabs instead of spaces, braces alignment and a few others.

I have been researching this a bit in some other apache projects and I  
have heard on argument against tabs. It's come up with svn commits and  
programs/emails etc that display the commits. They says tabs on a lot  
fo commits make the merge info really hard to read. I'm interested if  
anybody else has heard any other arguments against tabs that don't  
involve opinion.

Braces, ew that is the most hot topic there is. If you switch them, I  
think that would not be wise. My opinion on braces is we have to use  
the grandfathering clause here and accept what is already existent in  
the huge amount of code. Just my thought

> If there is a discussion being set up to discuss and finish the document,
> I'm willing to participate.

> --
> Christophe Herreman

I'd like to get this on the Flex site ASAP as well, anybody else have  
ideas how we can proceed to kill this bug soon?

Mike



Reply | Threaded
Open this post in threaded view
|

Re: Flex SDK code conventions

Jun Heider
In reply to this post by Christophe Herreman

> +1 for the coding conventions.

I'll give that a second +1

>
> Although I do want to point out that the coding conventions at
> http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions are not
> complete and there are a lot of "TBD"'s in the document.

I think our podling can have a Wiki right?  Any legal issues with moving over what's at opensource.adobe.com and then using that as our base?

>
> We've been using a variant subset of these conventions (so much for coding
> conventions)

Same at my company. I think the Adobe ones are a good start and with some tweaks would make everyone happy.
>
> Other changes are tabs instead of spaces, braces alignment and a few others.

Yes, tabs instead of spaces, agree.
>
> If there is a discussion being set up to discuss and finish the document,
> I'm willing to participate.

So would I.

-Jun
12