death to style guidelines

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Fri Aug 27 04:15:30 PDT 2010


  On 27.08.2010 14:15, Irakli Gozalishvili wrote:
> Hi,
>
> Please don't be too aggressive in replies, I know it's too ambitious & 
> may not lead to anything, but I still want to give it a try and 
> suggest to:
>
> Employ some of the decisions that being made with coffee script & 
> python in order to over all the wars regarding: 2 space vs 4 space vs 
> tabs, where to put braces, whether or not use optional semicolons. All 
> the style guidelines, just hurt developers, who have to switch 
> mentally every time they work on a project with a different style guides.

What exactly are you suggesting to "stop wars"? Though, I think today 
there are no such wars in more-less professional JS scripting (usually 
is used combination of Java's style guide with some local changes), 
majority in general is in agreement of how /current/ JS code should 
looks like.

The priority of applying some coding conventions and style guides are:

1. A local style guide used in company (the highest priority; it may 
shadow an official style guide of a technology if there is useful 
arrangement);
2. The official style guide provided by the main official resource of 
the technology (in this case -- http://ecmascript.org; is a 
/recommendation/ for a professionally formed code);
3. Local habit (the lowest priority; should be avoided. Used by 
beginners as a habit from previous technologies, e.g. underscore_case 
from C vs. camelCase used in JS).

And the only way to stop "some" mystic "wars" is to specify point (2), 
i.e. the official style guide suggested by the official resource of the 
technology. Many technologies have such recommendations, e.g. Python's 
"PEP 8" (http://www.python.org/dev/peps/pep-0008/), Java's official 
style guide 
(http://developers.sun.com/sunstudio/products/archive/whitepapers/java-style.pdf), 
etc. Only having this done and /exactly on the official resource/ may be 
a good reference in arguments when choosing a convention style guide.

And since ECMAScript has no such an official style guide, yeah, it would 
be good to write one. It is even good from a solid position -- other 
mainstream technologies have their recommendations for professionally 
written code. Some of them even suggest general structure of file system 
folders, e.g. Erlang for building their OTP applications, or Ruby (on 
Rails) which uses "convention over configuration" principle for 
decreasing a code syntactically and to have general, well-known to 
everyone, structure.

Currently, as a variant, the style guide of Mozilla may be treated as an 
"official", because JavaScript (and its inventor) are directly related 
with Mozilla. So, in arguments for choosing a convention style guide you 
may refer to their style guide too 
(https://developer.mozilla.org/en/JavaScript_style_guide, but this is 
mostly for scripting XUL as I see, and there are doubtful underscores, 
e.g. "UI_init").

Not bad (based on Java's style guide and, actually, is its complete 
"clone"/port) Crockford's description: 
http://javascript.crockford.com/code.html -- this one may be used in 
official document on http://ecmascript.org (2 or 4 spaces -- is needed 
to be decided though).

> Besides if I follow correctly it's being agreed to make backwards 
> incompatible syntax changes in new version of ECMAScript :)
>

No, only very-very needed incompatible changes (a "migrate tax"?). Here 
was a thread when I was confused regarding short notation of "funargs" 
(which is #) and why "fun" cannot be used -- I thought that "fun" will 
be a new keyword, but no, it's not worth about new keyword.

> As a side note, I'd like to also mention that coffee script managed to 
> reduce verbosity so match, making writing code so much better experience!
>

Yeah, as I mentioned, the good ways of removing all obsolete 
"syntactic/logical noise/garbage" and "bad parts" of previous versions 
is either to invent a new language (that is CoffeeScript does regarding 
JavaScript), or to plan some version which will be completely 
incomparable with previous code (let the Web crash with this new 
version!, if this new version will bring new highly-abstracted, modern 
and useful things). ES has such version -- it's the ES6 (aka Harmony), 
but it approves only very-very needed (and well-founded) changes (e.g. 
mentioned above "fun" won't be accepted because will "break the Web" as 
many scripts use "fun" as a name of simple "funargs"). Current approach 
with "use strict" (used now in ES5) is also a good way of, not so 
radical, but gradual removing of obsolete things (`with`, etc).

P.S.: explicit semicolon is also a "syntactic noise". It's just a 
consequence of some current well-known JS's ASI pitfalls (and 
minimizaton's issues) that an implicit semicolon was named as a bad 
practice. In general, it's a "noise" which (if needed) should be done by 
the machine, but not the human. If implemented well, ASI -- is a good 
idea. So, all that Ruby, Coffee, etc decrease this noise nicely. Though, 
I myself (as a habit) use always now explicit semicolon.

> Regards!
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
> Address: 29 Rue Saint-Georges, 75009 Paris, France 
> <http://goo.gl/maps/3CHu>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100827/aa7d7d55/attachment-0001.html>


More information about the es-discuss mailing list