*+1 global reformatting. *
*I am new to this but what I was thinking was to have a formatted style
that is for the project and then one for my own coding taste. When I
checkout/update, I would reformat it to my specifications/style. Once I am
done with the fix, I would then reformat it to the proj
+1 global reformatting.
I am new to this but what I was thinking was to have a formatted style that
is for the project and then one for my own coding taste. When I
checkout/update, I would reformat it to my specifications/style. Once I am
done with the fix, I would then reformat it to the projec
> I've never been a fan of highly detailed coding conventions. For example, I
> could care less if you use tab or space. Any modern editor can configure
> its tab width. I do care that a tab is four spaces though and want you to
> set your editor up that way.
I'm not fanatic about codding conve
On Jan 6, 2012, at 3:31 PM, Rick Winscot wrote:
> Jun,
>
> I apologize...
None necessary. :)
> I didn't mean to make it sound like everyone should be using command line
> SVN! My recommendation is limited to the poor soul(s) that will be tasked
> with getting the repository moved and ready t
Jun,
I apologize... I didn't mean to make it sound like everyone should be using
command line SVN! My recommendation is limited to the poor soul(s) that will be
tasked with getting the repository moved and ready to go... I've used a number
of GUI clients and found that most implement only a sub
On Jan 6, 2012, at 3:03 PM, Rick Winscot wrote:
> I'm not sure about SmartSVN - I'm a command-line kinda guy. In fact... for an
> operation this large I would recommend _not_ using a GUI client for sake of
> speed and stability.
>
I may be in the minority and I'm not opposed to using the comm
I'm not sure about SmartSVN - I'm a command-line kinda guy. In fact... for an
operation this large I would recommend _not_ using a GUI client for sake of
speed and stability.
Diff? You'll have tens-of-thousands of changes... I wouldn't worry about
running diff, since reformatting isn't going to
On 1/6/12 11:10 AM, "Rick Winscot" wrote:
> If, by chance, developers need to diff between rev50 and rev200... all they
> have to do is take rev50 and format it which should give them an approximation
> of rev101. If there is any question - they can always do a three-way compare
> of rev50 (re
+1
> From: Greg Reddin [mailto:gred...@gmail.com]
> On Fri, Jan 6, 2012 at 1:10 PM, Rick Winscot wrote:
> > If, by chance, developers need to diff between rev50 and rev200... all they
> have to do is take rev50 and format it which should give them an
> approximation of rev101. If there is any que
+1
Quoting Greg Reddin :
On Fri, Jan 6, 2012 at 1:10 PM, Rick Winscot wrote:
If, by chance, developers need to diff between rev50 and rev200...
all they have to do is take rev50 and format it which should give
them an approximation of rev101. If there is any question - they
can always d
On Fri, Jan 6, 2012 at 1:10 PM, Rick Winscot wrote:
> If, by chance, developers need to diff between rev50 and rev200... all they
> have to do is take rev50 and format it which should give them an
> approximation of rev101. If there is any question - they can always do a
> three-way compare of
Yes, past history should be preserved ( I'm not recommending that formatting be
done prior to the first commit ).
For clarification... after the initial commit of the SDK ( in its current state
to preserve historical comparison - lets call this rev100 ) the source can be
re-formatted to confor
On 1/6/12 10:05 AM, "Rick Winscot" wrote:
> If this path is followed...
>
> #1 establish coding conventions
> #2 commit SDK to SVN (as-is)
> #3 run the code formatter against SDK
> #4 commit / update reformatted code
> #5 begin work on Apache Flex
>
>
Until you go back in history. We are t
, January 5, 2012 at 7:00 PM, Douglas Arthur wrote:
> > -Original Message-
> > From: Carol Frampton [mailto:cfram...@adobe.com]
> > Sent: Thursday, January 05, 2012 4:55 PM
> > To: flex-dev@incubator.apache.org (mailto:flex-dev@incubator.apache.org)
> > Subject:
-Original Message-
From: David Arno
Reply-To: "flex-dev@incubator.apache.org"
Date: Fri, 6 Jan 2012 07:00:07 -0800
To: "flex-dev@incubator.apache.org"
Subject: RE: Flex SDK code conventions
>> From: Carol Frampton [mailto:cfram...@adobe.com]
>> Se
> From: Carol Frampton [mailto:cfram...@adobe.com]
> Sent: 05 January 2012 23:55
> I think it would be okay to move the Flex coding standard over to Apache.
>
> We/I updated the standard about a year ago with some changes people
wanted,
> like allowing line lengths up to 100 chars. We didn't ta
+1 to what Doug said. Reformat before anyone commits and have a single code
format style. It will be easier on everyone to not have to be conscious of
multiple coding styles and will allow us to turn auto-format on save and
never have the hodge podge mix of coding styles that is seen in the Flex
SD
> -Original Message-
> From: Carol Frampton [mailto:cfram...@adobe.com]
> Sent: Thursday, January 05, 2012 4:55 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex SDK code conventions
>
> I think it would be okay to move the Flex coding standard over to Apac
On Jan 5, 2012, at 4:54 PM, Carol Frampton wrote:
> I think it would be okay to move the Flex coding standard over to Apache.
That would be awesome!
>
> We/I updated the standard about a year ago with some changes people
> wanted, like allowing line lengths up to 100 chars. We didn't take the
xes should be
done in the style of the code around it.
Carol
-Original Message-
From: "j...@realeyes.com"
Reply-To: "flex-dev@incubator.apache.org"
Date: Thu, 5 Jan 2012 14:01:50 -0800
To: "flex-dev@incubator.apache.org"
Subject: Re: Flex SDK code convent
> +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
> +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
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
2012/1/4 Carol Frampton
> 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
2012/1/5 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.
That would be excellent, if someone would be willing to do th
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.
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
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 i
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
te
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 anot
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 Ro
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 <
roge...@rogeliocastillo.com> wrote:
> maybe a
#x27;s better for the collaborative efforts on large
>projects.
- Doug
-Original Message-
From: Michael Schmalle [mailto:m...@teotigraphix.com]
Sent: Wednesday, January 04, 2012 2:57 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex SDK code conventions
This is kind of what I
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 Forma
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 tel
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 wrote:
> There is a coding standard but unfortunately not everyone chose to follow
> it, or only followed the parts they liked.
>
> http://opensour
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 s
+1 , if it can be done with FlexFormatter it would be even better
On 04/01/12 22:54, "Carol Frampton" 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+Conventio
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: Micha
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/mediawi
40 matches
Mail list logo
