Archive for May 9th, 2011|Daily archive page

Douglas Crockford JavaScript coding conventions

Link to coding conventions: http://javascript.crockford.com/code.html

List of headings at the coding conventions site:

  • JavaScript files
  • Indentation
  • Line Length
  • Comments
  • Variable Declarations
  • Function Declarations
  • Names
  • Statements
    • Simple Statements
    • Compound Statements
    • Labels
    • return Statement
    • if Statement
    • for Statement
    • while Statement
    • do Statement
    • switch Statement
    • try Statement
    • continue Statement
    • with Statement
  • White-space
  • Bonus Suggestions
    • {} and []
    • , (comma) Operator
    • Block Scope
    • Assignment Expressions
    • === and !== Operators
    • Confusing Pluses and Minuses
    • eval is Evil

JsLint, Missing ‘New’

I had these errors all over the place in JsLint. Did some looking into it.

It’s a matter of coding conventions. Whether I agree with the convention or not, the first letter of a function “capitalized”, is a convention floated by Mr. Crockford’s JsLint that such functions represent an object constructor (and in JS, functions are first-class objects).

IMHO, conventions are nice if followed or understood by most. From here on out I may follow this convention, but I’m not about to go through all my JS code and re-write. Caveat: unless I get paid to do so.

Since JS functions could be anything from plain-old subroutine, an object, an argument in another function, etc… I can see where some type of convention would help.

On the flip side, does it really matter? Wouldn’t the flavor of function being declared be implied in the context of the application in which it was declared? Sort of like the multiple meaning of some words in the English language, where meaning is understood in the context the word was used?