4 ms·

Few of the examples you listed are arbitrary, in fact Crockford describes precisely why he chose them as conventions. In nearly all cases he came up with these

Few of the examples you listed are arbitrary, in fact Crockford describes precisely why he chose them as conventions. In nearly all cases he came up with these conventions to help coders avoid common pitfalls due to unfortunate aspects of the JavaScript language. function foo(){ myGlobal = "foo"; } var myGlobal; 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. "Do not use _ (underbar) as the first character of a name. It is sometimes used to indicate privacy, but it does not actually provide privacy. " It's private because you weren't invited to use it, not because I have a bomb waiting for you. No, it's private because it throws an error if you try to use it outside of the proper scope. From what I can tell about Python, for example, adding underbars enforces privacy, JavaScript doesn't. "Global variables should be in all caps." umm, no. That convention is reserved for constants. That convention in other languages is for constants. Crockford points out that js doesn't have constants. He also constantly points out the dangers of global variables, how you should minimize their use. The purpose of all caps is to give a visual cue that they're global, the purpose of all caps in other languages is to give a visual cue that they're constants. "Each group of statements (except the default) should end with break, return, or throw. Do not fall through." Arbitrary. I think DRY is preferable when it's warranted. 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. "Avoid doing assignments in the condition part of if and while statements. " It's a legitimate convention if wrapped with an extra pair of parenthesis. Note that Mozilla's strict mode will honor this convention. Crockford points out the problems you can run into doing that: Is if (a = b) { a correct statement? Or was if (a == b) { intended? It's easy enough to tell if you're the one who wrote it, but what happens to the poor sorry schlub who's trying to debug the code later on (especially if that schlub is you 6 months later)?

unwind 17y ago
From what I can tell about Python, for example, adding underbars enforces privacy, JavaScript doesn't. That's not true, an initial underscore is simply used as the convention to indicate that something is private: >>> class Foo(object): ... def __init__(self): ... self._bar = 48 ... >>> a=Foo() >>> a._bar 48
- mdg 17y ago
  Au contraire, double underscore does make it "private". Trying to access a double underscore attribute directly will throw an AttributeError. >>> class Foo(object): ... def __init__(self): ... self.__a = 42 ... def look_here(self): ... print self.__a ... >>> f = Foo() >>> f.__a Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'Foo' object has no attribute '__a' >>> f.look_here() 42
  - tkaemming 17y ago
    A bit off topic, but double underscores don't actually make members in Python truly private, but mangles the attribute name to prevent you from accessing it unless you really need to: http://docs.python.org/tutorial/classes.html#private-variables http://docs.python.org/tutorial/classes.html#private-variabl... >>> class Foo(object): ... def __do_something(self): ... print 'something was done' ... >>> f = Foo() >>> f.__do_something() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Foo' object has no attribute '__do_something' >>> f._Foo__do_something() something was done
    - mdg 17y ago
      You are 100% correct. This is a good example of Python making it harder for you to do the wrong thing. Sure.. you could access that "private" attribute, but you have to do it in a way that isn't obvious, and definitely more hard to read.
TNO 17y ago

unwind 17y ago

From what I can tell about Python, for example, adding underbars enforces privacy, JavaScript doesn't. That's not true, an initial underscore is simply used as the convention to indicate that something is private: >>> class Foo(object): ... def __init__(self): ... self._bar = 48 ... >>> a=Foo() >>> a._bar 48

mdg 17y ago
Au contraire, double underscore does make it "private". Trying to access a double underscore attribute directly will throw an AttributeError. >>> class Foo(object): ... def __init__(self): ... self.__a = 42 ... def look_here(self): ... print self.__a ... >>> f = Foo() >>> f.__a Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'Foo' object has no attribute '__a' >>> f.look_here() 42
- tkaemming 17y ago
  A bit off topic, but double underscores don't actually make members in Python truly private, but mangles the attribute name to prevent you from accessing it unless you really need to: http://docs.python.org/tutorial/classes.html#private-variables http://docs.python.org/tutorial/classes.html#private-variabl... >>> class Foo(object): ... def __do_something(self): ... print 'something was done' ... >>> f = Foo() >>> f.__do_something() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Foo' object has no attribute '__do_something' >>> f._Foo__do_something() something was done
  - mdg 17y ago
    You are 100% correct. This is a good example of Python making it harder for you to do the wrong thing. Sure.. you could access that "private" attribute, but you have to do it in a way that isn't obvious, and definitely more hard to read.

TNO 17y ago