incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: Flex SDK code conventions
Date Fri, 06 Jan 2012 18:05:10 GMT
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


...there should be no issue with previous or future diffs. 

Cheers,

Rick Winscot


On Thursday, January 5, 2012 at 7:00 PM, Douglas Arthur wrote:

> > -----Original Message-----
> > From: Carol Frampton [mailto:cframpto@adobe.com]
> > Sent: Thursday, January 05, 2012 4:55 PM
> > To: flex-dev@incubator.apache.org (mailto: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 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 take the time to
> > eliminate all the TBDs.
> > 
> > I will strongly advocate for 4 spaces rather than tabs. Too many apps mess up
> > the tabs or use 8 spaces rather than 4 by default.
> > 
> > I'm not sure I want to see existing code reformatted because it gets very
> > hard to go back to earlier revisions and see what changed. New modules
> > should be written to whatever the coding standard is. Bug fixes should be
> > done in the style of the code around it.
> > 
> > Carol
> 
> I'm going to have to disagree on not reformatting the existing codebase. I've been in
this situation before and understand it does cause some issues with past comparisons, but
the goal is to hopefully move forward and not have to be doing much of that. At worst case,
two previous revisions can be compared against each other, and then the revision in question
can be compared to the initially imported and formatted revision, which wouldn't have any
changes other than re-formatting. This way going forward, all the code is consistent and can
be easily followed along with. In the long run, this solution has proven to be very valuable
and productive in my experience.
> 
> I agree with all your other points.
> 
> - Doug 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message