or another nice one:
var a = [some array];
if (a.length == 1){
console.log(a[0])
} else for (var i = a.length; i--;){
console.log(a[i])
}
Most important thing is to pick one style, and stick with it.
However curly braces on newlines can be dangerous win JavaScript because of
ASI:
return {
a: 1
}
vs
return
{
a: 1
}
which have different behaviors. This is also described in this article
(didn't read it really myself though)
http://encosia.com/in-javascript-curly-brace-placement-matters-an-example/
On Fri, Mar 30, 2012 at 1:55 AM, Aaron Newton <[email protected]> wrote:
> MooTools code style (which is by no means any sort of standard other than
> with the moo-devs) says that any if/else block that can be expressed in
> single lines should be, that any if or else that requires more than one
> line (including a line wrap) means both use curly braces, that there is no
> space between ){
>
> Examples:
>
> if (foo) foo();
> else bar();
>
> if (foo){
> foo();
> } else {
> this.statement();
> takes.twoLines();
> }
>
> this would not be considered valid mootools style:
>
> if (foo) foo();
> else {
> this.statement();
> takes.twoLines();
> }
>
> It's also not frowned upon to use braces for one line statements where it
> would help make the intent more clear.
>
> I'll also note that in recent releases this kind of block started showing
> up:
>
>
>
>
> if (enumerables) for (var i = enumerables.length; i--;){
>
>
>
>
> k = enumerables[i];
>
>
>
>
> if (a.hasOwnProperty(k)) self.call(this, k, a[k]);
>
>
>
>
> }
>
>
>
> I.e. the if/for are on the same line.
>
>
> On Thu, Mar 29, 2012 at 4:39 PM, Sanford Whiteman <[email protected]>wrote:
>
>> One Style To Rule Them All (tm)... age-old problem, n'eh?
>>
>> I'm hardly the one to dictate, because I use the ternary operator more
>> often than sane people do. I find it easy to read, but YMMV.
>>
>> The general (don't quote me) consensus as to using curly braces is to
>> use them all the time, because that makes your code more maintainable
>> as you insert new lines. Then again, some very "pro" code leaves them
>> off for single-line statements -- but whether that code went through I
>> preprocessor I couldn't tell you.
>>
>> -- S.
>>
>>
>
