[Freeipa-devel] Proposed Javascript coding standards

[Adam Young]

On 09/13/2010 04:49 PM, Simo Sorce wrote:
> On Mon, 13 Sep 2010 11:44:53 -0400
> Adam Young<ayoung at redhat.com>  wrote:
>
>    
>> I've updated the page.  Bascially, I took the python coding standards
>> and aaplied them to our code.  THis seems to be the path of least
>> resistance.
>>
>> People used to Camel case will have to get used to underscores
>>
>> People used to putting underscores before private variables will go
>> through withdrawal
>>
>> There is something here for everyone to learn.
>>
>> Please review and provide feedback.
>>
>> https://fedorahosted.org/freeipa/wiki/Javascript_Coding_Standards
>>      
> The examples of "More than one space around an assignment (or other)
> operator to align it with another. " are undistinguishable from each
> other, I guess using<pre></pre>  in the markup around examples would be
> useful :-)
>
> I am not sure about:
>      Between a function declaration and the opening brace:
>
>          yes: function(){...} no: function() {...}
>
>
> In C code we have a policy of never opening the brace on the function
> declaration line, ie:
> 	function(arg) {
> is bad while we recommend
> 	function(arg)
> 	{
>
> Does this work for javascript ?
>    

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.


> We also forbid putting more than one statement on the same line, but I
> saw examples where you did do_one() do_two() do_three() on the same
> line after a parens close ... was that intended or is it a
> wiki formatting issue ?
>    

Either formatting issues or just there as part of emphasising a 
different aspect.  Putting more that one statment on a line is against 
the convention.  I'll try to clean up the examples.

> 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.


> The rest seems reasonable to me.
>
> Simo.
>
>