I mostly agree with the post in that the style's available from a language are resultant from the syntax rules and allowances provided by the interpretation of the given language. However, many of the comments under the post seem entirely absent of understanding code style. Style rules of a programming project do not exist to make code easier to read or understand, but that is what comments and beautifiers are for. Style rules exist purely for syntax cohesion of the various working parts to ensure that all code, in a given project, evaluates in a nearly same manner across the board. This has nothing to do with making life easier for developers, but only for ensuring that a project gets out the door in given time line with minimal execution complexity. Coherent code in a project also reduces maintenance costs with regard to testing and bug trapping with regard to future enhancements.
The lack of understanding exhibited by the comments serves to illustrate the complexity of software governance with regard to operational and security management of any given software project. In other words this is not a technology issue, but rather a human management issue provided with a technology flavor in an internal style guide document. If this one point about management does not enter the fray the entire discussion, of programing style in group development, the discussion is void.... in my opinion.
----- Original Message -----
From: Douglas Crockford <douglas@...>
Date: Monday, August 30, 2010 17:53
Subject: [jslint] Coding Style As A Failure Of Language Design