ES Style Question
I was wondering if a canonical guide for ECMAScript style and conventions exists - specifically I'm curious to find out what the historic precedence, rules and reasoning behind the capitalization of constructors and built-in objects, ie. Array or Math. Even _more_ specifically, there exists a fairly common convention that first letter capitalization is generally reserved for constructors that expect to be paired with new... obviously this is not a hard rule, but I'm curious if any documentation or articles exist regarding the subject. Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
I like http://javascript.crockford.com/code.html , though I disagree with leaving a space between function and ( for anonymous functions. http://www.jslint.com/ On Fri, Sep 9, 2011 at 10:45 AM, Rick Waldron waldron.r...@gmail.comwrote: I was wondering if a canonical guide for ECMAScript style and conventions exists - specifically I'm curious to find out what the historic precedence, rules and reasoning behind the capitalization of constructors and built-in objects, ie. Array or Math. Even _more_ specifically, there exists a fairly common convention that first letter capitalization is generally reserved for constructors that expect to be paired with new... obviously this is not a hard rule, but I'm curious if any documentation or articles exist regarding the subject. Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
Also, style guides with 2 spaces indention are also good and wide-spread
(other things are the same as described in the link which Mark gave --
this is Java's style guide by the way).
On 09.09.2011 22:10, Mark S. Miller wrote:
I like http://javascript.crockford.com/code.html , though I disagree
with leaving a space between function and ( for anonymous functions.
Since function name is optional in case of an expression, a space after
the function may make sense.
function foo() {}
function () {} -- just name disappeared, all the other the same.
Or, an analogy -- you put a space after some statements which are
followed by the parenthesis, right? E.g.:
while (true) {}
if (false) {}
the same with function.
However, of course it's just a local style guides. E.g. in Erlang, space
is not put (as usually and in code of standard library) for function
expressions as in your variant:
Double = fun(X) - X * X.
(fun(X) X * X)(2)
OTOH there, in contrast with JS, `fun`s don't have names.
P.S.: Back to topic, the thing which I personally don't like is to put a
colon on a new line, as used in Node.js often:
var a = 10
, b = 20
, c = 30;
Of course it has advantages, e.g. for commenting one line, but literally
looks odd for me.
But in general ECMAScript has no style guide. As well as there is no
such language as ECMAScript (I mean, it's the sample implementation
which is called ECMAScript), and all others are just local style guides.
Usually that's said, either Java's style guide is used, or the same but
with 2 spaces.
Dmitry.
http://www.jslint.com/
On Fri, Sep 9, 2011 at 10:45 AM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
I was wondering if a canonical guide for ECMAScript style and
conventions exists - specifically I'm curious to find out what the
historic precedence, rules and reasoning behind the capitalization
of constructors and built-in objects, ie. Array or Math. Even
_more_ specifically, there exists a fairly common convention that
first letter capitalization is generally reserved for constructors
that expect to be paired with new... obviously this is not a
hard rule, but I'm curious if any documentation or articles exist
regarding the subject.
Thanks!
Rick
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
Thanks for all the input. I'm actually aware of and have studied quite
thoroughly both of the resources that were provided - I'm kind of a
stickler for style guides.
I was actually very specifically looking for an answer regarding First
letter casing for non-constructor built-in objects, ie. Math and Proxy. I
think the legacy Java style guide influence addresses the question as best
as I can hope for.
Thanks
Rick
On Fri, Sep 9, 2011 at 3:11 PM, Tom Schuster t...@schuster.me wrote:
var a = 10
, b = 20
, c = 30;
Ugh the first time i saw this, i wondered who came up with this.
The Google style guide also isn't too bad
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xmlcript.crockford.com/code.html
, though I disagree with
/wrong button
On Fri, Sep 9, 2011 at 9:00 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Also, style guides with 2 spaces indention are also good and wide-spread
(other things are the same as described in the link which Mark gave --
this
is Java's style guide by the way).
On 09.09.2011 22:10, Mark S. Miller wrote:
I like http://javascript.crockford.com/code.html , though I disagree
with
leaving a space between function and ( for anonymous functions.
Since function name is optional in case of an expression, a space after
the
function may make sense.
function foo() {}
function () {} -- just name disappeared, all the other the same.
Or, an analogy -- you put a space after some statements which are
followed
by the parenthesis, right? E.g.:
while (true) {}
if (false) {}
the same with function.
However, of course it's just a local style guides. E.g. in Erlang, space
is
not put (as usually and in code of standard library) for function
expressions as in your variant:
Double = fun(X) - X * X.
(fun(X) X * X)(2)
OTOH there, in contrast with JS, `fun`s don't have names.
P.S.: Back to topic, the thing which I personally don't like is to put a
colon on a new line, as used in Node.js often:
var a = 10
, b = 20
, c = 30;
Of course it has advantages, e.g. for commenting one line, but literally
looks odd for me.
But in general ECMAScript has no style guide. As well as there is no such
language as ECMAScript (I mean, it's the sample implementation which is
called ECMAScript), and all others are just local style guides. Usually
that's said, either Java's style guide is used, or the same but with 2
spaces.
Dmitry.
http://www.jslint.com/
On Fri, Sep 9, 2011 at 10:45 AM, Rick Waldron waldron.r...@gmail.com
wrote:
I was wondering if a canonical guide for ECMAScript style and
conventions
exists - specifically I'm curious to find out what the historic
precedence,
rules and reasoning behind the capitalization of constructors and
built-in
objects, ie. Array or Math. Even _more_ specifically, there exists a
fairly
common convention that first letter capitalization is generally reserved
for
constructors that expect to be paired with new... obviously this is
not a
hard rule, but I'm curious if any documentation or articles exist
regarding
the subject.
Thanks!
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
I've used a few different javascript style guides over the years and the only
thing I can remember being consistent across all of them is that only
constructors get First letter casing.
I have to admit that the few times I've seen people using First letter casing
for non-constructors I've immediately decided that their code is no good, which
is probably a little reactionary on my part.
Crockford puts it well:
Constructor functions which must be used with the new prefix should start with
a capital letter. JavaScript issues neither a compile-time warning nor a
run-time warning if a required new is omitted. Bad things can happen if new is
not used, so the capitalization convention is the only defense we have.
-Mikeal
PS. I've now more or less settled on Isaac's style guide which is used by npm
https://github.com/isaacs/npm/blob/master/doc/coding-style.md although I do use
semicolons on new lines after large var declarations because I find that newer
developers think the statement ends ambiguously.
On Sep 9, 2011, at September 9, 20111:06 PM, Rick Waldron wrote:
Thanks for all the input. I'm actually aware of and have studied quite
thoroughly both of the resources that were provided - I'm kind of a
stickler for style guides.
I was actually very specifically looking for an answer regarding First letter
casing for non-constructor built-in objects, ie. Math and Proxy. I think the
legacy Java style guide influence addresses the question as best as I can
hope for.
Thanks
Rick
On Fri, Sep 9, 2011 at 3:11 PM, Tom Schuster t...@schuster.me wrote:
var a = 10
, b = 20
, c = 30;
Ugh the first time i saw this, i wondered who came up with this.
The Google style guide also isn't too bad
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xmlcript.crockford.com/code.html
, though I disagree with
/wrong button
On Fri, Sep 9, 2011 at 9:00 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Also, style guides with 2 spaces indention are also good and wide-spread
(other things are the same as described in the link which Mark gave -- this
is Java's style guide by the way).
On 09.09.2011 22:10, Mark S. Miller wrote:
I like http://javascript.crockford.com/code.html , though I disagree with
leaving a space between function and ( for anonymous functions.
Since function name is optional in case of an expression, a space after the
function may make sense.
function foo() {}
function () {} -- just name disappeared, all the other the same.
Or, an analogy -- you put a space after some statements which are followed
by the parenthesis, right? E.g.:
while (true) {}
if (false) {}
the same with function.
However, of course it's just a local style guides. E.g. in Erlang, space is
not put (as usually and in code of standard library) for function
expressions as in your variant:
Double = fun(X) - X * X.
(fun(X) X * X)(2)
OTOH there, in contrast with JS, `fun`s don't have names.
P.S.: Back to topic, the thing which I personally don't like is to put a
colon on a new line, as used in Node.js often:
var a = 10
, b = 20
, c = 30;
Of course it has advantages, e.g. for commenting one line, but literally
looks odd for me.
But in general ECMAScript has no style guide. As well as there is no such
language as ECMAScript (I mean, it's the sample implementation which is
called ECMAScript), and all others are just local style guides. Usually
that's said, either Java's style guide is used, or the same but with 2
spaces.
Dmitry.
http://www.jslint.com/
On Fri, Sep 9, 2011 at 10:45 AM, Rick Waldron waldron.r...@gmail.com
wrote:
I was wondering if a canonical guide for ECMAScript style and conventions
exists - specifically I'm curious to find out what the historic precedence,
rules and reasoning behind the capitalization of constructors and built-in
objects, ie. Array or Math. Even _more_ specifically, there exists a fairly
common convention that first letter capitalization is generally reserved
for
constructors that expect to be paired with new... obviously this is not a
hard rule, but I'm curious if any documentation or articles exist regarding
the subject.
Thanks!
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Re: ES Style Question
On 9 September 2011 16:06, Rick Waldron waldron.r...@gmail.com wrote:
I was actually very specifically looking for an answer regarding First
letter casing for non-constructor built-in objects, ie. Math and Proxy. I
think the legacy Java style guide influence addresses the question as best
as I can hope for.
These *did* come to us via Java (well, not Proxy), but they are hardly a
matter of style; they are a matter of specification.
Generally we name constructor functions with CapitalLeadingCamelCase and
everything else with smallLeadingCamelCase. I think I picked this up from
JavaScript: The Definitive Guide, 2nd Edition, by David Flanagan, about
4,000 years ago.
As for other matters of style, I am a big proponent of brace-on-a-line in
C-syntax languages, however this has proven to be a problem in practice with
JavaScript due to the interaction between automatic semicolin insertion and
object literal syntax in return statements:
return
{
Hello: world
};
is not the same as
return {
Hello: world
}
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
Mikeal,
So, the Math object is no good?
Rick
-- Sent from my Palm Pre
On Sep 9, 2011 4:27 PM, Mikeal Rogers lt;mikeal.rog...@gmail.comgt; wrote:
I've used a few different javascript style guides over the years and the only
thing I can remember being consistent across all of them is that only
constructors get First letter casing.nbsp;
I have to admit that the few times I've seen people using First letter casing
for non-constructors I've immediately decided that their code is no good, which
is probably a little reactionary on my part.
Crockford puts it well:
Constructor functions which must be used with
thenbsp;newnbsp;prefixnbsp;should start with a capital letter. JavaScript
issues neither a compile-time warning nor a run-time warning if
anbsp;requirednbsp;newnbsp;is omitted. Bad things can happen
ifnbsp;newnbsp;is not used, so the capitalization convention is the only
defense we have.
-Mikeal
PS. I've now more or less settled on Isaac's style guide which is used by
npmnbsp;https://github.com/isaacs/npm/blob/master/doc/coding-style.mdnbsp;although
I do use semicolons on new lines after large var declarations because I find
that newer developers think the statement ends ambiguously.
On Sep 9, 2011, at September 9, 20111:06 PM, Rick Waldron wrote:Thanks for all
the input. I'm actually aware of and have studied quite thoroughly both of the
resources that were provided - I'm kind of a stickler for style guides.
I was actually very specifically looking for an answer regarding First letter
casing for non-constructor built-in objects, ie. Math and Proxy. I think the
legacy Java style guide influence addresses the question as best as I can hope
for.
Thanks
Rick
On Fri, Sep 9, 2011 at 3:11 PM, Tom Schuster lt;t...@schuster.megt; wrote:
gt;var a = 10
gt; nbsp;, b = 20
gt; nbsp;, c = 30;
Ugh the first time i saw this, i wondered who came up with this.
The Google style guide also isn't too bad
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xmlcript.crockford.com/code.html
, though I disagree with
/wrong button
On Fri, Sep 9, 2011 at 9:00 PM, Dmitry Soshnikov
lt;dmitry.soshni...@gmail.comgt; wrote:
gt; Also, style guides with 2 spaces indention are also good and wide-spread
gt; (other things are the same as described in the link which Mark gave -- this
gt; is Java's style guide by the way).
gt;
gt; On 09.09.2011 22:10, Mark S. Miller wrote:
gt;
gt; I like http://javascript.crockford.com/code.html , though I disagree with
gt; leaving a space between function and ( for anonymous functions.
gt;
gt; Since function name is optional in case of an expression, a space after the
gt; function may make sense.
gt;
gt; function foo() {}
gt; function () {} -- just name disappeared, all the other the same.
gt;
gt; Or, an analogy -- you put a space after some statements which are followed
gt; by the parenthesis, right? E.g.:
gt;
gt; while (true) {}
gt; if (false) {}
gt;
gt; the same with function.
gt;
gt; However, of course it's just a local style guides. E.g. in Erlang, space is
gt; not put (as usually and in code of standard library) for function
gt; expressions as in your variant:
gt;
gt; Double = fun(X) -gt; X * X.
gt; (fun(X) X * X)(2)
gt;
gt; OTOH there, in contrast with JS, `fun`s don't have names.
gt;
gt; P.S.: Back to topic, the thing which I personally don't like is to put a
gt; colon on a new line, as used in Node.js often:
gt;
gt; var a = 10
gt; nbsp; , b = 20
gt; nbsp; , c = 30;
gt;
gt; Of course it has advantages, e.g. for commenting one line, but literally
gt; looks odd for me.
gt;
gt; But in general ECMAScript has no style guide. As well as there is no such
gt; language as ECMAScript (I mean, it's the sample implementation which is
gt; called ECMAScript), and all others are just local style guides. Usually
gt; that's said, either Java's style guide is used, or the same but with 2
gt; spaces.
gt;
gt; Dmitry.
gt;
gt;
gt; http://www.jslint.com/
gt;
gt; On Fri, Sep 9, 2011 at 10:45 AM, Rick Waldron
lt;waldron.r...@gmail.comgt;
gt; wrote:
gt;gt;
gt;gt; I was wondering if a canonical guide for ECMAScript style and
conventions
gt;gt; exists - specifically I'm curious to find out what the historic
precedence,
gt;gt; rules and reasoning behind the capitalization of constructors and
built-in
gt;gt; objects, ie. Array or Math. Even _more_ specifically, there exists a
fairly
gt;gt; common convention that first letter capitalization is generally
reserved for
gt;gt; constructors that expect to be paired with new... obviously this is
not a
gt;gt; hard rule, but I'm curious if any documentation or articles exist
regarding
gt;gt; the subject.
gt;gt; Thanks!
gt;gt; Rick
gt;gt; ___
gt;gt; es-discuss mailing list
gt;gt; es-discuss@mozilla.org
gt;gt; https://mail.mozilla.org/listinfo/es-discuss
gt;gt;
gt;
gt;
gt;
gt; --
gt; nbsp; nbsp; Cheers,
gt;
Re: ES Style Question
Wes,
I was referring to the _very_ first reply to this thread.
Thanks again
Rick
-- Sent from my Palm Pre
On Sep 9, 2011 4:48 PM, Wes Garland lt;w...@page.cagt; wrote:
On 9 September 2011 16:06, Rick Waldron lt;waldron.r...@gmail.comgt; wrote:
I was actually very specifically looking for an answer regarding First letter
casing for non-constructor built-in objects, ie. Math and Proxy. I think the
legacy Java style guide influence addresses the question as best as I can hope
for.
Thesenbsp; *did* come to us via Java (well, not Proxy), but they are hardly a
matter of style; they are a matter of specification.
Generally we name constructor functions with CapitalLeadingCamelCase and
everything else with smallLeadingCamelCase.nbsp; I think I picked this up from
JavaScript: The Definitive Guide, 2nd Edition, by David Flanagan, about 4,000
years ago.
As for other matters of style, I am a big proponent of brace-on-a-line in
C-syntax languages, however this has proven to be a problem in practice with
JavaScript due to the interaction between automatic semicolin insertion and
object literal syntax in return statements:
return{
nbsp; Hello: world };
is not the same as
return {nbsp; Hello: world
}
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Invitation to connect on LinkedIn
I'd like to add you to my professional network on LinkedIn. - welefen welefen li welefen at WEL China Confirm that you know welefen li: https://www.linkedin.com/e/8e5fqf-gsdxao6c-62/isd/4153471975/hLSXQDwZ/?hs=falsetok=3D2Ij4mLw_B4U1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/8e5fqf-gsdxao6c-62/Iocz4oqCggDFH9UmcXlXFcrnNrQOzGhmhET/goo/es-discuss%40mozilla%2Eorg/20061/I1433347864_1/?hs=falsetok=3UkUHpmLA_B4U1 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
