Single ' or double " quotes?

[DrKen]

In looking at various JavaScript examples, I see a lot of
inconcsistency over when to use ' ' and when to use " ". For
example, should I code
var user = document.getElementById('userid');
or
var user = document.getElementById("userid");

Is there a rule I can follow to decide which kind of quote to use?
I'm used to languages that are very very picky about this. Thanks.

Ken

 

[Gregor Kofler]

Am 2011-06-15 20:45, DrKen meinte:

In looking at various JavaScript examples, I see a lot of
inconcsistency over when to use ' ' and when to use " ". For
example, should I code
var user = document.getElementById('userid');
or
var user = document.getElementById("userid");

It's completely irrelevant.

Is there a rule I can follow to decide which kind of quote to use?

Whatever you prefer. I prefer double quotes. Though I can't really say
why...

I'm used to languages that are very very picky about this. Thanks.

What do you mean by "picky"? There are differences for example with PHP
(interpolation with double quotes), but PHP is not really "picky" about
that - it won't shout when using double quotes when not necessary.


Gregor

 

[Jukka K. Korpela]

It's completely irrelevant.

Taken in isolation, yes.

Single quotes are however convenient in client-side JavaScript, when
your code might be embedded into event attributes, conventionally
delimited by double quotes.

 

[Evertjan.]

Jukka K. Korpela wrote on 15 jun 2011 in comp.lang.javascript:

Taken in isolation, yes.

Single quotes are however convenient in client-side JavaScript, when
your code might be embedded into event attributes, conventionally
delimited by double quotes.

And also in serverside javascript,
when building html strings
or complex structures.

sql strings also need single quotes.

 

[Dr J R Stockton]

In comp.lang.javascript message <a64fb8c6-7a68-4405-a8e8-65b3fd22bb65@j1
3g2000pro.googlegroups.com>, Wed, 15 Jun 2011 11:45:50, DrKen

In looking at various JavaScript examples, I see a lot of
inconcsistency over when to use ' ' and when to use " ". For
example, should I code
var user = document.getElementById('userid');
or
var user = document.getElementById("userid");

Is there a rule I can follow to decide which kind of quote to use?
I'm used to languages that are very very picky about this. Thanks.

I don't see that anyone has actually said that the closing quote must be
literally the same as the opening one.

If you want to put a ' in the string, it's easier to use " quotes.
If you want to put a " in the string, it's easier to use ' quotes.

If you want to put the string in something that is already in " quotes,
use ' quotes, and /vice versa/.

If you want to put a " in a string already in " quotes, use \".
If you want to put a ' in a string already in ' quotes, use \'.

In a string, instead of " you can write \x22 or \u0022.
In a string, instead of ' you can write \x27 or \u0027.

If you do not want to use \, then you can write something like
'aaa"bbb' + "ccc'ddd".

Also, read (its free) ECMA 262 version 5 section 7.8.4.

 

[Jukka K. Korpela]

I don't see that anyone has actually said that the closing quote must be
literally the same as the opening one.

I thought that was pretty obvious if you think about the very idea of
string literal delimiters.

If you want to put a ' in the string, it's easier to use " quotes.
If you want to put a " in the string, it's easier to use ' quotes.

Marginally easier. This hardly justifies mixed style, i.e. using "
quotes for some literals and ' quotes for some. I tend to be sloppy and
use quotes by my mood, but I shouldn't.

It’s best to stick to one delimiter, normally ' quotes (for a few
reasons, none of which is compelling but sufficient for making a
choice). And in the rare cases where you need a quote inside the
literal, you simply escape it with “\â€.

When the string literal contains an expression in a natural language, it
normally should not contain " or ' at all, as they are “computer
quotesâ€, not correct in any human language (though still widely used as
a holdover from the bad old times when typewriters and ASCII ruled the
Earth). When you use proper language-specific quotation marks, you can
write then inside a literal with no escaping, e.g.
'it’s easy'
or (if you haven’t learned how to type proper quotes)
'it\u2019s easy'

 

[Dr J R Stockton]

I thought that was pretty obvious if you think about the very idea of
string literal delimiters.

Never presume that the other fellow has the same idea of what is
obvious.

I recall being telephoned by an inexpert TurboPascal programmer in
another building, who said that he had an error and gave its number -
perhaps 203. I recognised that; he needed to put something like
{$M 4096, 0, 0}
as the first line. So I said to put a first line of 'open-twiddly-
brackets dollar Em space ... '. No good, compiler objected. We checked
verbally that he had put what I said, or so we thought. Only when I
remembered that, over the network, I could actually see the code did I
perceive that he'd parsed my words as 'open twiddly-brackets dollar Em
space ...' and so he had written open{$M 4096, 0, 0) or
similar.

teral, you simply escape it with “\â€.

When the string literal contains an expression in a natural language,
it normally should not contain " or ' at all, as they are “computer
quotesâ€, not correct in any human language (though still widely used as
a holdover from the bad old times when typewriters and ASCII ruled the
Earth). When you use proper language-specific quotation marks, you can
write then inside a literal with no escaping, e.g.
'it’s easy'
or (if you haven’t learned how to type proper quotes)
'it\u2019s easy'

Life is too short and inter-cranial memory too cluttered to use fancy
quotes except when publishing professionally - and then one needs to be
sure that the user's font will always understand them.

<FAQENTRY> OTOH, it might be useful to have in the FAQ a small subset of
\x##, \u####, and &word; codings, with a link or two to a fuller list.
<http://en.wikipedia.org/wiki/List_of_Unicode_characters> is useful, and
more concise than what unicode.org has. And one can take a local copy
and excise the superfluous - I expect that few of us will foresee much
need to write in Linear B - though the \u28## block may some day become
needed.

 

[Jukka K. Korpela]

Never presume that the other fellow has the same idea of what is
obvious.

That would mean ending all human communication. All efforts to
communicate must postulate a huge amount of assumptions (though partly
varying). I don' know why you felt it to be necessary to state the
obvious. It seems that you wanted to say that the delimiter cannot
appear in the delimited string.

Life is too short and inter-cranial memory too cluttered to use fancy
quotes except when publishing professionally

At least when you use JavaScript on or for web pages, you are using it
when publishing. Don't you think the quality should be professional?

It's the ASCII quotes that are "fancy", computerese. They were
introduced on mechanical typewriters, than transferred to early
character codes on computers (and keyboards), lumping together opening
and closing quotation marks and several other characters, even intending
the quotes play, via overprinting, dual roles as diacritic marks. There
is little reason to preserve that barbaric treatment of human language
punctuation.

As I mentioned, using proper punctuation marks _avoids_ trouble, since
in JavaScript, as in most computer languages, they are just character
data with no syntactic meaning.

- and then one needs to be
sure that the user's font will always understand them.

Do you expect to find many fonts that do not contain the quotation marks
as used in English?

<FAQENTRY> OTOH, it might be useful to have in the FAQ a small subset of
\x##, \u####, and&word; codings, with a link or two to a fuller list.

Hardly. Any subset would be arbitrary and biased. FAQs are no
replacement for references. And &word; codings aren't JavaScript at all.

<http://en.wikipedia.org/wiki/List_of_Unicode_characters> is useful, and
more concise than what unicode.org has.

And infinitely more unreliable. It's also far too long to give an
overview, and it's far to limited to give a complete list. Even the page
itself says: "This article may be too long to read and navigate
comfortably. Please consider splitting content into sub-articles and
using this article for a summary of the key points of the subject."
That's a polite way of saying that it is overlong, messy, and hasn't
much point in it.

 

[Dr J R Stockton]

2011-06-18 23:39, Dr J R Stockton wrote:

At least when you use JavaScript on or for web pages, you are using it
when publishing. Don't you think the quality should be professional?

No. That would in fact be deceptive, since I am not a professional
publisher. And nothing else about my site is professional either, since
professional work is checked before release to the public. I just, as
an amateur, do the best I can to get my meaning across and give the
right results.

As I mentioned, using proper punctuation marks _avoids_ trouble, since
in JavaScript, as in most computer languages, they are just character
data with no syntactic meaning.


Do you expect to find many fonts that do not contain the quotation
marks as used in English?

That's not the point. I do not expect that every font used will contain
the fancy quotes; I do not know, and I do not need to. And it's not
only a matter of fonts used by Web browsers; if I copy'n'paste source
here, I don't want readers to be interrupted by seeing coded characters.

Hardly. Any subset would be arbitrary and biased. FAQs are no
replacement for references. And &word; codings aren't JavaScript at
all.

An intelligent FAQ write will not be much biased; and, if he is, it does
not matter. Those who write JavaScript commonly write HTML and need
such as &nbsp; .. &emsp; for spacing in forms. Eschew pedantry.

 

[Jukka K. Korpela]

That's not the point.

So what _is_ your point then?

I do not expect that every font used will contain
the fancy quotes; I do not know, and I do not need to.

So if you don't know about it, why are you referring to font issues at
all? If I mentioned that the proper multiplication sign in
natural-language texts is "×", not "*" as in programming languages,
would you also worry about fonts? Why aren't you worrying about the need
to be sure that the user's font will always understand the characters "
and '?

And it's not
only a matter of fonts used by Web browsers; if I copy'n'paste source
here, I don't want readers to be interrupted by seeing coded characters.

Then don't copy and paste source here; copy and paste a URL instead.

Those who write JavaScript commonly write HTML and need
such as&nbsp; ..&emsp; for spacing in forms.

No they don't. HTML specifications explicitly tell them to use style
sheets and not space characters for layout. And &emsp; would be a
particularly bad choice if someone really used it - _it_ may create real
font problems.

Besides, if people who write JavaScript commonly do something else as
well, that doesn't imply it should be discussed in a JavaScript FAQ. For
example, the FAQ is no place for discussing eating, sleeping, walking,
or sex, even though many JavaScript programmers surely do some of these
and may have serious problems with them.

 

[Ry Nohryb]

(...)
Besides, if people who write JavaScript commonly do something else as
well, that doesn't imply it should be discussed in a JavaScript FAQ. For
example, the FAQ is no place for discussing eating, sleeping, walking,
or sex, even though many JavaScript programmers surely do some of these
and may have serious problems with them.

That would be going too far for a JS FAQ. In spanish: Korpela: te has
pasado tres pueblos.

But every JS programmer will sooner or later need to know about/have
to deal with (HTML) character entities, so I'd agree with Stockton.

 

[Jukka K. Korpela]

But every JS programmer will sooner or later need to know about/have
to deal with (HTML) character entities, so I'd agree with Stockton.

First of all, the JavaScript FAQ is supposed to address JavaScript
questions, not any questions that JavaScript programmers might
encounter. And your logic is faulty: far more JS programmers eat, at
least sometimes, than play with ”character entities”, yet you agreed
that food issues don’t belong to the JavaScript FAQ.

”Characters entity” itself is a misnomer, and it is easy to get both
terms and content wrong when FAQ authors write about a topic area that
is not the intended area of the FAQ. With anything related to
characters, that is virtually certain.

The purpose of a FAQ is _not_ to show off in everything vaguely related
to the topic that its authors think they know about. The JavaScript FAQ
appears to be rather clean in this sense; it should be kept that way.

 

[Ry Nohryb]

First of all, the JavaScript FAQ is supposed to address JavaScript
questions, not any questions that JavaScript programmers might
encounter. And your logic is faulty: far more JS programmers eat, at
least sometimes, than play with character entities , yet you agreed
that food issues don t belong to the JavaScript FAQ.

Characters entity itself is a misnomer, and it is easy to get both
terms and content wrong when FAQ authors write about a topic area that
is not the intended area of the FAQ. With anything related to
characters, that is virtually certain.

The purpose of a FAQ is _not_ to show off in everything vaguely related
to the topic that its authors think they know about. The JavaScript FAQ
appears to be rather clean in this sense; it should be kept that way.

Agreed, the purpose of the FAQ is not to show off in anything

There are things that aren't -strictly speaking- JS, such as the DOM,
or a browser, but are so closely related to JS that deserve entries in
a JS FAQ, or not ?

E.g. http://www.jibbering.com/faq/#domRef or http://www.jibbering.com/faq/#doNotTry

 

[Jukka K. Korpela]

There are things that aren't -strictly speaking- JS, such as the DOM,
or a browser, but are so closely related to JS that deserve entries in
a JS FAQ, or not ?

Yes, but the discussion was about "character entities". There's no
reason to discuss them, or comparable details of markup, in JavaScript
FAQ. For comparison: "JavaScript: The Definitive Guide", over 1,000
pages, recommended in the FAQ, has a very broad topic area, covering
client-side JavaScript, DOM, jQuery, APIs, and what else. But it does
not seem to say a word about "character entities" under any name I can
imagine. And this is just fine, so the FAQ, which should be essentially
shorter than such book, has hardly any reason to start listing
"character entities" picked up by someone or his brother.

If there is any reason to even mention "character entities" (properly
called "entity references" and "character references" in classic HTML,
"character references" in HTML5), then it's the potential confusion of
different "escape notations" in JavaScript, HTML, and CSS. A character,
say the minus sign U+2212, can be written as \u2212 in JavaScript,
− in HTML, and \002212 in CSS. But there's little than needs to
be said or could be said about this except that they are different
notations used in different languages, so take care. Surely no need to
start listing specific characters. But if you did start listing
characters, why would you show the HTML codes in a JavaScript FAQ,
rather than the JavaScript codes?

 

[Dr J R Stockton]

So what _is_ your point then?

That is the point. You seem to be answering on first reading, which is
always a mistake.

So if you don't know about it, why are you referring to font issues at
all? If I mentioned that the proper multiplication sign in natural-
language texts is "×", not "*" as in programming languages, would you
also worry about fonts? Why aren't you worrying about the need to be
sure that the user's font will always understand the characters " and
'?

That's a new-university undergraduate-level remark.

Then don't copy and paste source here; copy and paste a URL instead.

You are a newcomer. We have been quite happy to have copy'n'pasted code
here for at least a decade. That is often, but not always, all that is
called for.

In my case, many of my code snippets never exist in a file, Web or local
- and I don't have Web space to waste. They are tested in my js-
quick.htm or js-demos.htm.

No they don't. HTML specifications explicitly tell them to use style
sheets and not space characters for layout. And &emsp; would be a
particularly bad choice if someone really used it - _it_ may create
real font problems.

It works correctly in IE, Firefox, Safari, Chrome (Windows). It does
not work correctly in Opera, but renders as a hollow brick. If Opera
read my pages - and I give them URLs demonstrating their faults - it
might help to shame them into getting it right. Note : I don't use it
for exact spacing; it provides an inexpensive way of generating a space
about as big as three or for letters. My target readership will not
care about seeing a brick in such a position; they'll mostly thing that
it's an unusual but satisfactory separator.

It would be different, of course, if I were writing sales sites, or
teaching others to do so.

But I do mean simple spacing : example :

<div class=CEN>
Do this : <input type=radio name=JKK> &emsp;
Do that : <input type=radio name=JKK checked>
</div>

Worse things need fixing in browsers; I cannot use &plusmn; or &there4;
because my Firefox renders the "inky" parts of their glyphs OK but
appears to think they have invisible ascenders and descenders about 4ex
tall.

Besides, if people who write JavaScript commonly do something else as
well, that doesn't imply it should be discussed in a JavaScript FAQ.
For example, the FAQ is no place for discussing eating, sleeping,
walking, or sex, even though many JavaScript programmers surely do some
of these and may have serious problems with them.

Undergraduate again.