Added proposed Development Guide (including style guides)

[Javier Pedemonte]

I added a Development Guide wiki page.  It's purpose is to ensure that all of the Maqetta developers are on the same page, in both style and functionality.

Still a work in progress, so please respond if you have any issues or suggestions.

Javier

- maqetta team

[Jon]

Proposals look good to me, although I'm disappointed that in 2011 we
are still having to indent with spaces.

Jon

On Aug 23, 7:57 am, Javier Pedemonte <jhpedemo...@gmail.com> wrote:
> I added a Development Guide<https://github.com/maqetta/maqetta/wiki/Development-Guide> wiki

[Adam L. Peller]

The Google stuff looks like a great starting point.  Some suggested additions:

ES5 array functions: forEach, some, every, indexOf, etc.:  Yes.  Avoid for-loop constructs when one of these would be a simple replacement. They're more readable.

ES5 methods, in general: Yes (except for runtime code).  There's no going back for us.

eval: don't use it at all.  For evaluating JSON, use JSON.parse() for well-formed (i.e. quoted) JSON.  Use dojo.fromJson() for more forgiving -- basically an eval, but let Dojo be responsible for doing the eval so we don't litter our code with what might be eval for other purposes.  Also, if needed, there is a monkey patch that can make dojo.fromJson secure.

[Javier Pedemonte]

Added Adam's suggestions.

Also:

- Added a line to enable JS validation in Eclipse.

- Filled out the Separation of Concerns section (although, it could probably use a better title).

Javier

- maqetta team

[Jon]

Latest proposal still says "4 spaces". I thought we were going to use tabs instead of space. Otherwise, looks good to me.

[Javier Pedemonte]

I updated the wiki page and the Eclipse Formatter Profile to use tabs instead of space.

Javier

- maqetta team

[billreed63]

Allow 100-character long lines (instead of 80), this is to restrictive and in my option makes for choppy hard to read code. While I agree we do not want excessively long lines 

I find code that is restricted to 100 characters harder to understand than code the is allowed to follow in a readable manner. 

I would like to see us adapt a more accommodating approach on line length. and allow lines to extent past this limit for the sake of readability.

[Adam L. Peller]

how about 'avoid' instead of making it a requirement.  If it's the rare exception that the line exceeds 100, I think we could live with it.  I was able to look at all the long lines in Context.js and find something wrong with them.  Also, AMD will make our lines a lot shorter when we replace all the davinci.blah.blah.blah references with a local variable.

-Adam

[Bill Reed]

I like that 'avoid' is a good compromise.

[Wayne Vicknair]

i agree. this is the kind of compromise i was seeking in the meeting yesterday.

--wayne

[Javier Pedemonte]

I'm fine with "avoid", but I don't want this to be an easy out.  I have yet to see a greater-than-100-char line that couldn't easily wrapped and still remain readable.  If you find one, please provide it as an example.

As I emailed yesterday, the Google Style Guide for JavaScript has a section on wrapping Function Arguments (go to the Code formatting section, 3rd subsection down).

Javier

[Javier Pedemonte]

I added a line stating that we should now be using `bind()`, instead of `dojo.hitch` or `var self = this`...

Javier

- maqetta team