On 09/13/2010 04:49 PM, Simo Sorce wrote:
On Mon, 13 Sep 2010 11:44:53 -0400
Adam Young<ayo...@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

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.

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

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.

    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

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.


Freeipa-devel mailing list

Reply via email to