bevacqua / js Goto Github PK

You need to quantify why style checking is painful. Your statement is especially contradicting as enforcing braces is something that the style tool you link to will actually do. I have never worked in a shop where a style of code wasn't enforced. Agreeing on a style might be arbitrary but it's usually done for a good reason.

I'm confused why a function expression is worse than a function declaration (https://github.com/bevacqua/js#functions). You site hoisting as the reason why they're bad. But aren't function expressions better for this very reason? That is, by declaring the function as a variable, it will remain in the order that it is defined in the scope, rather than switching around as a function declaration would be hoisted above other variable definitions and make the code less clear.

Also, it seems that by defining a function in a variable, one would get better error feedback (for example if someone tried to use the function before it was declared they would get a TypeError).

See http://www.unicodegirl.com/function-statement-versus-function-expression.html

IMHO function expressions make for clearer code as it is closer to what the interpreter is seeing, making the code more predictable and thus easier to manipulate.

This may all be moot with ES6 now standardized and most of the community moving over to block-scoped let, but I'm just curious about your reasoning because I always thought about it the other way around.

whatefsww

I've always had a problem with the default values trick using ||. What if you want to default the used value to 0?

https://github.com/bevacqua/js/tree/3aa78500a96e4ca5cf13867593081da07b83f31c#everyday-tricks

Here https://github.com/bevacqua/js#functions .

IMHO, function declaration is preferred since it is easy for debugging.

Hi sir,
i am facing the issue at comparison operators.
Comparison operators are not working properly i a function.

alert(1>2); //output is true
//but
function a(){
alert(1>2); //output is null showing alert but not have any value
}

In a reused form component for both the record creation and the record modification, is it acceptable to use ternary operators instead of if/else like this?

this.formAction === 'edit' && this.recordValue ?
    this.recordForm.setValue(this.recordValue) :
    this.recordForm.reset();

It's a clear-cut case. With code-formatting of new-line and indent, it's quite readable. And in the foreseeable future, for each condition of the formAction, the business logic is unlikely to be changed.

ah

The above code doesn't support many browsers even if we remove the return statements and replace it with console.log.

The current link[29] to james.padolsey.com is 404.

• line 740
  • If the left-hand value is [falsy][29]
• line 830
  • [29]: http://james.padolsey.com/javascript/truthy-falsey/

First time here!

Under Conditionals, you demonstrate the following, below, as "Good":

if (err) { throw err; }

Yes, the practice of using brackets when they're optional is indeed good.

Aside from that, however, I don't believe opening and closing curly brackets should ever be on the same line, as a rule. It encourages poor readability.

When you're visually scanning code, this is much harder to parse:

if (a === b) { doSomething(); }
else if (a === c) { doSomethingElse(); }
else { doTheThing(); }

Than this:

if (a === b) { 
    doSomething();
}
else if (a === c) { 
    doSomethingElse();
}
else {
    doTheThing();
}

Or even this:

if (a === b) { 
    doSomething();
} else if (a === c) { 
    doSomethingElse();
} else {
    doTheThing();
}

Density is not a good thing.

Keeping code terse and line numbers down can sometimes be counter-productive. Same-line opening/closing brackets give developers the illusion of a code block having less logic in it than it actually has.

If I see a method with three lines as I'm scanning, I will likely perceive the complexity to be less than if I see a method that does the exact same thing but is nine lines. The risk is that other developers will come along and stuff more logic into that method with three lines than the one with nine. Code blocks with same-line open/close brackets end up growing larger in complexity, discouraging abstraction and separation of concerns.

White space, on the other hand, is a good thing.

@bevacqua Thanks for the amazing work done.

Use Function() as a "no-op".

function (cb) {
  setTimeout(cb || Function(), 2000);
}

why not use if-else and do not call setTimeout at all ?

Can we Add length literal in Array i.e will Help to find the length of Array.

array.length
return : x: size of Array

I want to use Sourcegraph for js code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/bevacqua/js. (It should only take 30 seconds.)

Thank you!

I want to mix two or three colors to one color.
I don’t care about color components(Using r,g,b or other things)

If there is any way to do this, please let me know!
thanks,

Linting section ,first line

On the other hand?

بلاي][هكر[توب

When declaring a function, always use the function expression form instead of function declarations.

Yet underneath you show that var foo = function(){}; is bad whilefoo function(){}; is good

I thought function expression is the storing of anonymous or named functions in a variable and function declaration is a named function without a variable assignment.

Automatic Semicolon Insertion (ASI) is not a feature. Don't rely on it. It's super complicated and there's no practical reason to burden all of the developers in a team for not possessing the frivolous knowledge of how ASI works. Avoid headaches, avoid ASI.

Always add semicolons where needed

To quote standard out of laziness:

No semicolons – It's fine. Really!

There is only a single rule that is a real "gotcha!" and memorizing a single rule is not "frivolous knowledge of ASI".

I'm impartial about whether to avoid or use semicolons. However spreading FUD as the reason to use them should not be how a responsible developer does it. It's largely a stylistic issue. Feel free to advocate for the use of semi-colons but please make sure you aren't doing so under false reasons.

Regardless, I'd take a programmer with frivolous knowledge of how a language actually parses and functions over one who doesn't any day of the week.

Relevant to above statement:
http://www.slideshare.net/olvemaudal/deep-c

There is a substantial performance hit associated with using arguments in certain ways, as outlined in this great post. While [].slice.call(arguments) is the cleanest way to cast arguments to an array, and in many cases it's not necessary to fully optimize, I think it's at least worth mentioning.

I don't think it's good to recommend using || for setting default value to variables. It's nice shortcut but it can cause trouble when valid input (0, false, '') is converted to default value. I would recommend mentioning explicitly these dangers in that chapter or add chapter about more safe default value assigning

function example(value) {
  if (typeof value === 'undefined') {
    value = 'defaultValue';
  }
}