*+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
Unlike Vegas? ;-)
I'm not trying to side-step the list... I'm just not an initial committer and
have nowhere to drop the archive for public consumption. More importantly, I
want to hear back from Earnest before I send a derivative work of his out into
the public/wild.
If it is determined that
, 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:
Mike,
Getting the formatter to run on the command line was an experiment... I really
wasn't sure of the outcome - but I'm happy that it came together and with very
little effort. My aim was to get familiar with prior art... I've been all
through the Flex Formatter source and am now taking a loo
-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: Rick Winscot [mailto:rick.wins...@gmail.com]
> Sent: 06 January 2012 16:06
> Rogelio - can you send me your direct mail? (so we don't clutter the list)
Please don't do this. The topic is of interest to others (myself included.)
Remember the rule that if it doesn't happen here, it doesn'
Rogelio - can you send me your direct mail? (so we don't clutter the list)
Cheers,
Rick Winscot
On Thursday, January 5, 2012 at 4:15 PM, Rogelio Castillo Aqueveque wrote:
> Hi Rick
>
> I'd like to try the tool out (mac)
>
> R
>
> On 5/01/2012, at 6:08 PM, Rick Winscot wrote:
>
> > I have
> 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
Hi Rick,
I'm looking at ANTLR3 now... and am entertaining a ground-up rewrite
to get rid of unnecessary dependencies, improve performance, and
flesh out some attachment points for other tooling (i.e. FlexPMD).
What are you exactly proposing?
Have you though about contacting Ernest about 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
That is essentially what I did - took all the dependencies and wrapped them up
into a single executable jar. The final product is a little over 20mb - it
would be great if we could shrink this down a bit.
Getting the formatter to run on the command line is a first step...
unfortunately the only
Hi Rick
Ernest actually commented on my blog post today about this very thing!
Saying his formatter can run on the command line with minimal eclipse
jars.
Quoting him
"FYI, you can run FlexFormatter from the command line if that helps.
It still requires some Eclipse jars, but you don’t h
Hi Rick
I'd like to try the tool out (mac)
R
On 5/01/2012, at 6:08 PM, Rick Winscot wrote:
> I have command-line version of the Flex Formatter ready to test... if anyone
> (preferably on a Mac) would like to give it a go - let me know.
>
> The tool is executed on the command-line as:
>
> jav
I have command-line version of the Flex Formatter ready to test... if anyone
(preferably on a Mac) would like to give it a go - let me know.
The tool is executed on the command-line as:
java -jar ApacheFlexFormatter.jar -settings=[ path to .properties file ]
-path=[ file, files, or directory ]
> +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
> > >>> know.
> > > > >>>
> > > > >>> The problem is Flash Builder is not the only ide in town.
> > > > >>>
> > > > >>> Mike
> > > > >>>
> > > > >>>
> >
gt; > >>> Mike
> > > >>>
> > > >>>
> > > >>> Quoting Douglas Arthur :
> > > >>>
> > > >>>> I for one vote that we suggest developers to use FlexFormatter and
> > > >>>>
is not the only ide in town.
> > >>>
> > >>> Mike
> > >>>
> > >>>
> > >>> Quoting Douglas Arthur :
> > >>>
> > >>>> I for one vote that we suggest developers to use FlexFormatter and
> > >
;>>> 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
>
I
>>>> even believe there's a settings file floating around from Adobe.
>>>>
>>>> http://sourceforge.net/apps/mediawiki/flexformatter/index.php?title=Prefere
>>>> nces
>>>>
>>>>
>>>> - Doug
>>>>
&
php?title=Preferences
- 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 comm
nd 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-
> &
#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
//sourceforge.net/apps/mediawiki/flexformatter/index.php?title=Preferences
>>
>>
>> - Doug
>>
>> -Original Message-
>> From: Michael Schmalle [mailto:m...@teotigraphix.com]
>> Sent: Wednesday, January 04, 2012 2:48 PM
>> To: flex-dev@incubat
Reply-To: "flex-dev@incubator.apache.org"
Date: Wed, 4 Jan 2012 13:48:25 -0800
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 wha
e: Wed, 4 Jan 2012 13:48:25 -0800
> 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 th
iawiki/flexformatter/index.php?title=Preferences
- 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 co
display/flexsdk/Coding+Conventions
>
>I am in favor of a coding standard. I like uniform looking code.
>
>Carol
>
>-Original Message-
>From: Michael Schmalle
>Reply-To: "flex-dev@incubator.apache.org"
>Date: Wed, 4 Jan 2012 13:48:25 -0800
>To: "flex-d
: Michael Schmalle
Reply-To: "flex-dev@incubator.apache.org"
Date: Wed, 4 Jan 2012 13:48:25 -0800
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
e.net/apps/mediawiki/flexformatter/index.php?title=Preferences
- 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 as
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 th
50 matches
Mail list logo
