[Freeipa-devel] Proposed Javascript coding standards

[Pavel Zůna]

On 2010-09-13 23:46, Simo Sorce wrote:
> On Mon, 13 Sep 2010 17:02:19 -0400
> Adam Young<ayoung at redhat.com>  wrote:
>
>> The is a really nasty bug that the "same line" policy avoids.
>> Javascript often attempts to guess where you meant to put semicolons,
>> and puts the in for you, without telling you.
>>
>> return
>> {
>>       status: true;
>> };
>>
>>
>> actually returns undefined.  I fully acknowledge that this is brain
>> dead.  There are some really brain-dead "features" in JavaScript.
>>
>> It is easier to be consistent here, hence the rule "always put it on
>> the opening statement line.
>
> Ok, in that case please note the rationale in the coding style.
> Also though in that case I think function() { (with the space) is
> better than function(){, unless the sapce is what causes javascript to
> put in the automatic ';'. If that's the case I hate it :)
>

For functions I also prefer:
func()
{
}
but only use it for file scope (thus global) functions in Javascript.

For nested functions and every other compound statement:
func() {
}

I wouldn't mind switching to the second variant for everything for 
consistency.

>>> We also banned C++ style comments in C code, /* */ is preferred and
>>> should never be added on the same line of code but only on the
>>> previous line.
>>>
>>
>> I'm OK with that rule.  C++ style comments are only to be used for
>> commenting out code, which probably shouldn't get checked in anyway.
>
> Given space matters in javascript I say that the git history is where
> you put unused code, not in comments :)
>
> Simo.
>

I don't like the 'spec' object to be used instead of naming each 
variable separately for parameter lists of functions. I think it's very 
artificial. I do agree, that being able to do this:

function some_func(spec) {
    return (spec.param1 + spec.param2);
}

var some_var = some_func({'param1': 'value1', 'param2': 'value2'})

is nice, but it makes the code less readable. You can't tell directly 
what parameters the function takes.

The rest is almost 100% compatible with my coding style, so naturally I 
agree. :D

Pavel