Great to hear about the upcoming source tree browsing! And congratulations to Adobe for this very positive move - although I'd personally like to see the term "software freedom" used instead of "open source" :-)

I have a suggestion for an existing Adobe project that could be brought into this site: The Adobe Open Type Font Developer Kit has a lot of Python programs licensed under the BSD license, but some proprietary C programs too. It would be great if the AOTFDK could be fully freed and hosted on this new area! :-)

Many thanks!

I'd like to offer some feedback on the coding "Flex SDK coding conventions and best practices"

(I'd actually like to rewrite the whole thing and remove failures)

haha, actually just a couple of points and questions:

what's the benefit of

if()
{

}

as opposed to:

if() {

}

If we're getting strict about code formatting standards the same set of semantics should apply accross the board ie: keeping per line character count to less than or equal to 80 for minimizing horizontal scrolling. Why not minimize extraneous nonsensical whitespace that actually decreases in readability in large programs with high levels of nested functions and operations?

If opened for discussion a tighter set of constraints can be developed which would actually contribute more to rapid development practices. (and less funky looking code)

I'm not sure if you've ever had to deal with gibberish like this in some *ah hehm* developers code...

if()
{
if()
{
if()
{
if()
{
if()
{

}

}

}

}

}

just the difference in vertical whitespace alone is worth considering this... - even though i would still freak out if i saw anyone on my team coding without proper nesting. I'd make them write python for a week or two to "learn them a lesson".

if() {
if() {
if() {
if() {
if() {
}
}
}
}
}

ps I totally hijacked this topic - apologies. I can create a new one if this is worth following up on...

I didn't attempt to preserve formatting in that post intentionally to illustrate some poor code I've encountered.
Everyone has their preference, I've found that in lengthy programs the vertical scrolling gets ridiculous really fast. Right from the start a program that consists of five functions and twenty if statements gets 25 extra line breaks, add else blocks and it gets a little silly.

I can't see the benefit: the visual que from a rapid access point of view actually favors omitting extraneous line breaks:

eg:

if()
{

}
else
{

}
// 8 lines
vs.

if() {

} else {

}
//5 lines

b Next issue then:

function f(a:Array /* of Number */):Array /* of Object */
{
...
}

This I have an actual legitimate issue regarding rapid development and corporate implementation guidelines that are pretty prevalent (at least in my 11 or so years of development)

b case in point:

For a particular change order made to some integral part of a hypothetical proprietary business application.

/*
// Change order #011198
// Client[Client Name] requested return value changed to unsigned integer from array.
// 12/5/2008 2:30pm montana p montana@email.com
.*/

function f(a:Array /* of Number */, i:uint ):uint /* of Object */
{
return uint;
...
}

/*
function f(a:Array /* of Number */):Array /* of Object */
{
return array;
}
.*/

b ^ this obviously doesn't work, and costs more money to do since the programmer must take the time to edit out the nested comment blocks, or use // single line comments

b The preferred method is:

// usage: f(Array of Number);
function f(a:Array):Array { /* of Number */
return array;
}

The resultant change:

/*
// Change order #011198
// Client[Client Name] requested return value changed to unsigned integer from array.
// 12/5/2008 2:30pm montana p montana@email.com
.*/

// usage: f(Array of Number, uint);
function f(a:Array, i:uint):uint {
return i;
}

/*
// usage: f(Array of Number);
function f(a:Array):Array {
return array;
}
.*/

b this method has the added benefit of adding rudimentary documentation for the function call itself

There's always room for improvement. Saying "we already have so much code formatted x way so we shouldn't change our practices", even if there may be value to doing so, is no good. I understand the hesitance. However, if there is evidence supporting a particular design pattern's
inherent value, it should be considered notwithstanding existing methodologies.

thank you for your time, I look forward to more amazing work from the adobe team.

(sorry about not taking the time to format this post a little nicer...back to work)