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:cfram...@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
