Congrats on the new OSS site, some suggestions...

Question

Adobe folks: congratulations on this new open source site. It looks well done, and a good step for Adobe. I have a few suggestions:
(1) svn via https. Many of your customers will be behind corporate firewalls that may implement a transparent HTTP proxy. Some of these proxies (Symantec's enterprise firewall offerings, for example) do not understand Delta-V WebDAV methods used by subversion breaking svn over http. Consider using https to get around this and to marginally increase security (most svn users will cache ssl certificates, preventing a hypothetical, but unlikely man-in-the-middle injection of evil code into a checkout).
(2) Wiki-type offerings. Much of the site is very much producer-to-consumer distribution model; there may be value in increasing community contribution (e.g. documentation) above and beyond the forums.
(2) Some kind of source browsing (like Trac, for a good example of this done well in commercial open-source projects, look at Apple MacOSForge pages such as this: http://trac.calendarserver.org/projects/calendarserver ).
Sean Upton

Answer 1

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 [email protected]
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 [email protected]
// 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)