4 ms·

"This is clear if you only have this one function, but with a large js file I know I'd rather not be searching through the code for global variables. That's als

by TNO 17y ago

"This is clear if you only have this one function, but with a large js file I know I'd rather not be searching through the code for global variables. That's also why "Inner functions should follow the var statement", it's an easy way to keep track of scope." And what about functions in the outer scope? Why should one be forced to place them in a particular order to use them in an inner scope? God forbid if you have this: function first(){ //stuff someVal = second() //stuff } function second(){ //stuff anotherVal = first() //stuff } "No, it's private because it throws an error if you try to use it outside of the proper scope." This is what I'm talking about: function Point(x, y){ this._x = parseInt(x,10); this._y = parseInt(y,10); } Point.prototype = { get x() this._x, set x(v) this._x = parseInt(v,10), get y() this._y, set y(v) this._y = parseInt(v,10) } You simply don't document the "private" properties. Pretending JavaScript is more robust than it is helps no one and wastes memory. "That convention in other languages is for constants. Crockford points out that js doesn't have constants." It's been supported since JavaScript 1.5. "The purpose of all caps is to give a visual cue that they're global" Hungarian notation works fine thank you. "Crockford used to think the same. He tells the story of a user who suggested fall-through should be flagged by JSLint. Crockford gave him a detailed response explaining that there was nothing wrong with fall-through. The user agreed, and included a bug report for JSLint in his response. Crockford found the bug in JSLint and it was caused by... fall-through." I don't see the relevance. "if (a = b) {" I've already pointed out that there is already a common, testable convention in place: if((a = b)){ Use Mozilla's strict mode and you'll be able to see the difference.

isleyaardvark 17y ago
And what about functions in the outer scope? Why should one be forced to place them in a particular order to use them in an inner scope? I can't speak for Crockford, but I would note that "function foo() = {}" is equivalent to "var foo = function () {}", so it may be for the same reason for declaring global variables up top. You simply don't document the "private" properties. Pretending JavaScript is more robust than it is helps no one and wastes memory. I don't think we're talking about the same thing. I'm talking about private variables, the same way they are used in other programming languages: variables that cannot be accessed from outside the object. When you try to access private variables in other languages it throws an error, and you want it to throw an error, that's why you make it private. You don't want it accessed. Crockford shows how you can do that in js. Consider this version of the code you gave: function Point(x, y){ this._x = parseInt(x,10); this._y = parseInt(y,10); var _private = 'foo' } Point.prototype = { get x() this._x, set x(v) this._x = parseInt(v,10), get y() this._y, set y(v) this._y = parseInt(v,10) } var myPoint = new Point(100,50); alert(myPoint._x); alert(myPoint._private); The last alert will show 'undefined', that's intentional. Const is not supported in IE (https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/Const https://developer.mozilla.org/En/Core_JavaScript_1.5_Referen...), and wasn't originally supported in js. I've already pointed out that there is already a common, testable convention in place: if((a = b)) Avoiding assignments in conditionals is general advice in more than just one language. Besides here's what Mozilla says about it: assignment in a conditional (Note: you can suppress this warning by including an extra set of parentheses around the assignment) (https://developer.mozilla.org/en/New_in_Rhino_1.6R6)* https://developer.mozilla.org/en/New_in_Rhino_1.6R6)* Also: It is advisable to not use simple assignments in a conditional expression, because the assignment can be confused with equality when glancing over the code. For example, do not use the following code:* If you need to use an assignment in a conditional expression, a common practice is to put additional parentheses around the assignment. In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice. Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt. If you disagree with some of them, hell, email the guy. He might explain it in better detail.
- TNO 17y ago
  "Const is not supported in IE [...] and wasn't originally supported in js." Which is an irrelevant point anyway since it still doesn't justify hijacking an already commonly accepted convention for some other purpose. "In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice." The point is that the meaning is clarified by using the convention. "It is advisable to not use simple assignments in a conditional expression,..." I would not presume to know what level of brevity is desirable for a developer in a given situation. Conventions like the one mentioned are available for clarification of such constructs. "Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt." Accepting an argument based on perceived authority is a logical fallacy. "the book on JavaScript" has some questionable things as well I hear: Function.prototype.method = function(name, func) { this.prototype[name] = func; return this; }; I do truly hope people don't consider such examples a good idea.

by TNO 17y ago

isleyaardvark 17y ago

And what about functions in the outer scope? Why should one be forced to place them in a particular order to use them in an inner scope? I can't speak for Crockford, but I would note that "function foo() = {}" is equivalent to "var foo = function () {}", so it may be for the same reason for declaring global variables up top. You simply don't document the "private" properties. Pretending JavaScript is more robust than it is helps no one and wastes memory. I don't think we're talking about the same thing. I'm talking about private variables, the same way they are used in other programming languages: variables that cannot be accessed from outside the object. When you try to access private variables in other languages it throws an error, and you want it to throw an error, that's why you make it private. You don't want it accessed. Crockford shows how you can do that in js. Consider this version of the code you gave: function Point(x, y){ this._x = parseInt(x,10); this._y = parseInt(y,10); var _private = 'foo' } Point.prototype = { get x() this._x, set x(v) this._x = parseInt(v,10), get y() this._y, set y(v) this._y = parseInt(v,10) } var myPoint = new Point(100,50); alert(myPoint._x); alert(myPoint._private); The last alert will show 'undefined', that's intentional. Const is not supported in IE (https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/Const https://developer.mozilla.org/En/Core_JavaScript_1.5_Referen...), and wasn't originally supported in js. I've already pointed out that there is already a common, testable convention in place: if((a = b)) Avoiding assignments in conditionals is general advice in more than just one language. Besides here's what Mozilla says about it: assignment in a conditional (Note: you can suppress this warning by including an extra set of parentheses around the assignment) (https://developer.mozilla.org/en/New_in_Rhino_1.6R6)* https://developer.mozilla.org/en/New_in_Rhino_1.6R6)* Also: It is advisable to not use simple assignments in a conditional expression, because the assignment can be confused with equality when glancing over the code. For example, do not use the following code:* If you need to use an assignment in a conditional expression, a common practice is to put additional parentheses around the assignment. In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice. Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt. If you disagree with some of them, hell, email the guy. He might explain it in better detail.

TNO 17y ago
"Const is not supported in IE [...] and wasn't originally supported in js." Which is an irrelevant point anyway since it still doesn't justify hijacking an already commonly accepted convention for some other purpose. "In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice." The point is that the meaning is clarified by using the convention. "It is advisable to not use simple assignments in a conditional expression,..." I would not presume to know what level of brevity is desirable for a developer in a given situation. Conventions like the one mentioned are available for clarification of such constructs. "Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt." Accepting an argument based on perceived authority is a logical fallacy. "the book on JavaScript" has some questionable things as well I hear: Function.prototype.method = function(name, func) { this.prototype[name] = func; return this; }; I do truly hope people don't consider such examples a good idea.