How to "cast" string "1 + 2 + 3" to a number?

[Iain Chalmers]

I don't agree with this sentiment. There is nothing wrong with the use
of double quotes there.

But single quotes are _quicker!_ Look:

#!/use/bin/perl -w
use strict;
use Benchmark;

timethese(1000000, {
'Double' => sub {my $string = "1 + 2 + 3";},
'Single' => sub {my $string = '1 + 2 + 3';},
});

gives:

Benchmark: timing 1000000 iterations of Double, Single...
Double: 0 wall secs(1.04usr+0.00sys=1.04 CPU) @ 961538.46/s (n=1000000)
Single: 1 wall secs(1.00usr+0.00sys=1.00 CPU) @ 1000000.00/s (n=1000000)

The single quotes save a _whopping_ 40nanoseconds per allocation on my
machine!

HTH, HAND!

big

 

[Uri Guttman]

MV> On Mon, 05 Jan 2004 08:10:38 +0100,

MV> I don't agree with this sentiment. There is nothing wrong with the use
MV> of double quotes there.

i consider it a useful style thing. why are single quotes even in perl
if doubles will work just fine? the reason is to document to the reader
of the code (e.g. the maintainer) that this string is not interpolated
so don't bother scanning it for variables or espape sequences. you write
code for others to read so conveying the most semantic information
possible to the reader is important. single quotes mean something
different than double quotes. so my rule and i teach this, is use single
quotes on all fixed strings.

uri

 

[Tad McClellan]

I do, just for the record.

But I've heard both Randal and TomC say they'd use double quotes there.

But single quotes are _quicker!_

Execution speed is not the issue. I know you were just kidding,
but it makes a nice segue to why _I_ don't use double quotes
unless I have to.

But single quotes are quicker when reading the code!


When I'm debugging I'm often looking for variables in the code.

It takes longer to determine that

"there are no variables in this whole long string!"

contains no variables, than

'there are no variables in this whole long string!'

because I can go to the next line as soon as I see the single quote.


[ My case gets a good deal weaker with 'short' strings or with

'there are no variables in this whole long string!', $var

though...
]

The single quotes save a _whopping_ 40nanoseconds per allocation on my
machine!

It ain't the silicon cycles that are important, it is the
grey-matter cycles that matter most.


When I see double quotes, I expect the programmer to have made use of
one of the two "extra" things they give you over single quotes.

When I get to the end of the string and there are none, I feel like
I've been tricked into spending time that I didn't need to spend.

 

[Tore Aursand]

I don't agree with this sentiment. There is nothing wrong with the use
of double quotes there.

It's wrong; You already have a string, so why should you stringify it? And
does/should anything inside that string interpolate? No.

This is explained in the Perl FAQ:

perldoc -q quoting

 

[Tassilo v. Parseval]

Also sprach Tad McClellan:

When I'm debugging I'm often looking for variables in the code.

It takes longer to determine that

"there are no variables in this whole long string!"

contains no variables, than

'there are no variables in this whole long string!'

because I can go to the next line as soon as I see the single quote.

Doesn't your editor has proper syntax-highlighting? For me, both double-
and single-quoted strings are rendered in a sort of whine-ish red.
Interpolated variables in double-quotes are light-blue and
escape-sequences orange.

Tassilo

 

[Uri Guttman]

TvP> Also sprach Tad McClellan:
TvP> Doesn't your editor has proper syntax-highlighting? For me, both double-
TvP> and single-quoted strings are rendered in a sort of whine-ish red.
TvP> Interpolated variables in double-quotes are light-blue and
TvP> escape-sequences orange.

i don't use that. and not all editors have it. and not all places where
i edit do i have it. it is a poor assumption that the reader of your
code has syntax highlighting. it is better to keep the reader informed
as to what kind of string you have by choosing the proper quotes.

uri

 

[Martien Verbruggen]

MV> On Mon, 05 Jan 2004 08:10:38 +0100,


MV> I don't agree with this sentiment. There is nothing wrong with the use
MV> of double quotes there.

i consider it a useful style thing. why are single quotes even in perl
if doubles will work just fine? the reason is to document to the reader
of the code (e.g. the maintainer) that this string is not interpolated

I know this argument. This discussion pops up regularly, and there are
probably as many people who subscribe to that view as people who don't.

What I was surprised about is that it is now being quoted as something
that you should not do, based on documentated reasons, rather than style
preferences.

I'm still waiting for the documentation reference. I already know the
style arguments.

so don't bother scanning it for variables or espape sequences. you write
code for others to read so conveying the most semantic information
possible to the reader is important. single quotes mean something
different than double quotes. so my rule and i teach this, is use single
quotes on all fixed strings.

And that's fine. But I object to just telling people "Don't use double
quotes when single quotes would do just as well", especially when it's
made more "authoritative" by invoking "the Perl documentation".

It is, after all, a style issue, and not one of correctness.

Martien

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

TvP> Also sprach Tad McClellan:

TvP> Doesn't your editor has proper syntax-highlighting? For me, both double-
TvP> and single-quoted strings are rendered in a sort of whine-ish red.
TvP> Interpolated variables in double-quotes are light-blue and
TvP> escape-sequences orange.

i don't use that. and not all editors have it. and not all places where
i edit do i have it. it is a poor assumption that the reader of your
code has syntax highlighting. it is better to keep the reader informed
as to what kind of string you have by choosing the proper quotes.

The major flaw in your reasoning is the assertion that my code would be
mostly for others. My production code is not, never.

Firstly, I am the one who types it. With a German keyboard layout (and
my particular way of using finger/hand combinations to produce certain
characters), " is more comfortably produced than '. This is because the
little finger of my left hand hits the left shift key and, while holding
it down, the middle finger of the same hand hits the key "2". For a
single quote, I need two hands (since I don't use the right shift key).

Secondly, I am also the one who spends more time reading my own stuff
than others do. I for sure know that I wont even trigger an editor when
I know it's not vim (or when I know it's vim but the terminal doesn't
support colors). Yes, I can be a bitch when my programming environment
isn't exactly as I want it.

And in the case that anyone other than me wants to read my code, well,
then he has to live with my style conventions. I'd rather tell him to
get a proper editor than chaning my style and feel uncomfortable all the
time.

Of course, things are entirely different when the programming is carried
out in a collaborative fashion with many people being on the project. In
such situations, I am happily willing to follow whatever coding
convention has been agreed on.

Tassilo

 

[Matt Garrish]

I'm still waiting for the documentation reference. I already know the
style arguments.

I suspect it's just a confusion with the perlfaq entry about double-quoting
variables when it's not needed. To throw in my two cents, I actually agree
with Uri that double-quotnig strings should only be done when using the
extra features it provides. I used to be a fan of double-quoting all my
strings for consistency, but Perl is all about laziness, and it really is
much faster to be able to see single quotes and not have to check for
interpolated variables or special characters. But as you say, it is all
about style.

Matt

 

[Uri Guttman]

MV> And that's fine. But I object to just telling people "Don't use double
MV> quotes when single quotes would do just as well", especially when it's
MV> made more "authoritative" by invoking "the Perl documentation".

i never claimed that. it could be in perlstyle but i haven't checked. it
shouldn't be in perldata.

MV> It is, after all, a style issue, and not one of correctness.

but it is correct style!!

uri

 

[Uri Guttman]

TvP> The major flaw in your reasoning is the assertion that my code
TvP> would be mostly for others. My production code is not, never.

my rules for coding:

code is for humans, not computers
code is for others, not yourself.

if you care so little about how others read your code, why not just
program in assembler or (gasp!) lisp? code is a way to describe the
logic of your program. it is not just instructions to the computer. we
pick a language which we like because it allows us to more easily
express our ideas, not because it makes the life of the computer
easier. now you may think you are the only one to read your code, but
that is not necessarily true. ever read and work with your own code (in
production!) 10 years later? you will most likely think the original
coder was a moron. i did

TvP> Firstly, I am the one who types it. With a German keyboard layout
TvP> (and my particular way of using finger/hand combinations to
TvP> produce certain characters), " is more comfortably produced than
TvP> '. This is because the little finger of my left hand hits the
TvP> left shift key and, while holding it down, the middle finger of
TvP> the same hand hits the key "2". For a single quote, I need two
TvP> hands (since I don't use the right shift key).

so get a better editor. i map keys in emacs to change keyboard layout
quirks (control to where $DIETY intended it, to the left of 'A').
you espouse using a syntax highlighting editor so this is the same
thing.

TvP> Secondly, I am also the one who spends more time reading my own
TvP> stuff than others do. I for sure know that I wont even trigger an
TvP> editor when I know it's not vim (or when I know it's vim but the
TvP> terminal doesn't support colors). Yes, I can be a bitch when my
TvP> programming environment isn't exactly as I want it.

ahh, so some others do read your code. then you are being selfish by not
coding for them. code doesn't live in a vacuum. it is a document of your
logic. others need as much semantic help as they can when reading
it. this is no different than picking good variable names (just a
smaller set of choices).

TvP> And in the case that anyone other than me wants to read my code,
TvP> well, then he has to live with my style conventions. I'd rather
TvP> tell him to get a proper editor than chaning my style and feel
TvP> uncomfortable all the time.

and you should get an editor that would help you type ' as easily as ".

TvP> Of course, things are entirely different when the programming is
TvP> carried out in a collaborative fashion with many people being on
TvP> the project. In such situations, I am happily willing to follow
TvP> whatever coding convention has been agreed on.

but you agree to use perl. perl has both quote styles for a reason. do
you use poor perl contructs elsewhere? no as you know better perl than
that. this is the same thing.

and even though i might not convince you, so this is for those others
who will read this thread.

uri

 

[Walter Roberson]

: code is for humans, not computers
: code is for others, not yourself.

One of my rules for coding is:

Using single-quotes results in broken perl -e scripts.
Compensating for that makes the -e'd script considerably less
readable and more error-prone than using double-quotes.

:if you care so little about how others read your code, why not just
rogram in assembler or (gasp!) lisp?

Now, how does it go these days? "... why don't you move to Russia?!"
has lost a lot of it's effect. I did see a " ... why don't you
move to Cuba?!" within the last 3 weeks. I think US popular
culture is still using "... then you must support terrorism!"


I write programs because there are tasks to do. perl allowed me to
accomplish those tasks in reasonable ways and it runs faster than
piping together nawk and sed and grep and ksh and whatever. Will
someone else ever read my code? I guess it -could- happen, but
knowing our financial situation, it seems -unlikely- for years yet.

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

TvP> The major flaw in your reasoning is the assertion that my code
TvP> would be mostly for others. My production code is not, never.

my rules for coding:

code is for humans, not computers
code is for others, not yourself.

if you care so little about how others read your code, why not just
program in assembler or (gasp!) lisp? code is a way to describe the
logic of your program. it is not just instructions to the computer. we
pick a language which we like because it allows us to more easily
express our ideas, not because it makes the life of the computer
easier. now you may think you are the only one to read your code, but
that is not necessarily true. ever read and work with your own code (in
production!) 10 years later? you will most likely think the original
coder was a moron. i did

My coding rules aren't much different from yours. However and since you
mentioned the logic of a program: for me, a string is a string
regardless of whether it interpolates something or not. Technically, the
result of

$var = "foo";
"foo$var"

and

'foobar'

is indistinguishable. So why should I draw a line between those two
things?

The fact that I can use use both single- and double-quotes is a matter
of convenience compared to languages where I can't freely exchange those
two, such as C.

And this also answers your question why I program in Perl instead of
assembler or Lisp: Perl is full of convenient little things. The
interchangeability of quotation marks is just one of them. And since I
am willing to squeeze every little bit of comfort out of Perl, I chose
to use mostly double quotes.

TvP> Firstly, I am the one who types it. With a German keyboard layout
TvP> (and my particular way of using finger/hand combinations to
TvP> produce certain characters), " is more comfortably produced than
TvP> '. This is because the little finger of my left hand hits the
TvP> left shift key and, while holding it down, the middle finger of
TvP> the same hand hits the key "2". For a single quote, I need two
TvP> hands (since I don't use the right shift key).

so get a better editor. i map keys in emacs to change keyboard layout
quirks (control to where $DIETY intended it, to the left of 'A').
you espouse using a syntax highlighting editor so this is the same
thing.

This might be a good suggestion, nonetheless. Some common characters
could be more accessible than they are now. This however wont make me
use the single quote in Perl more often. I was thinking about other
things now.

TvP> Secondly, I am also the one who spends more time reading my own
TvP> stuff than others do. I for sure know that I wont even trigger an
TvP> editor when I know it's not vim (or when I know it's vim but the
TvP> terminal doesn't support colors). Yes, I can be a bitch when my
TvP> programming environment isn't exactly as I want it.

ahh, so some others do read your code. then you are being selfish by not
coding for them. code doesn't live in a vacuum. it is a document of your
logic. others need as much semantic help as they can when reading
it. this is no different than picking good variable names (just a
smaller set of choices).

Indeed. Programming in my spare time and openly distributing the result
to the public and at the same time maybe not ensuring readability to the
most insignificant extent is mighty selfish. Outrageous! ;-)

TvP> And in the case that anyone other than me wants to read my code,
TvP> well, then he has to live with my style conventions. I'd rather
TvP> tell him to get a proper editor than chaning my style and feel
TvP> uncomfortable all the time.

and you should get an editor that would help you type ' as easily as ".

TvP> Of course, things are entirely different when the programming is
TvP> carried out in a collaborative fashion with many people being on
TvP> the project. In such situations, I am happily willing to follow
TvP> whatever coding convention has been agreed on.

but you agree to use perl. perl has both quote styles for a reason. do
you use poor perl contructs elsewhere? no as you know better perl than
that. this is the same thing.

For me those different styles of quoting have a different background. I
use single quotes when I'd have to use too many escapes otherwise as in

'From: $DIETY <[email protected]>'

That's why Perl offers yet more ways of creating string literals
(here-docs, q/qq with an almost arbitrary set of delimiters).

Tassilo

 

[Martien Verbruggen]

MV> And that's fine. But I object to just telling people "Don't use double
MV> quotes when single quotes would do just as well", especially when it's
MV> made more "authoritative" by invoking "the Perl documentation".

i never claimed that. it could be in perlstyle but i haven't checked. it
shouldn't be in perldata.

I didn't mean that you calimed it. But this part of the thread started
at a post in which someone (I'm too lazy now to look it up) did claim
that the Perl documentation stated that you shouldn't use double
quotes when single quotes suffice. Since I've never noticed that
entry, I was wondering where it was, and when it was added.

MV> It is, after all, a style issue, and not one of correctness.

but it is correct style!!

I see the smiley, but I still don't agree .

Martien

 

[Martien Verbruggen]

It's wrong; You already have a string, so why should you stringify it? And
does/should anything inside that string interpolate? No.

This is explained in the Perl FAQ:

perldoc -q quoting

That explains why you shouldn't quote variables with double quotes
when _no quotes_ would achieve the same thing. In other words, it
discusses things like

print "$var";

versus

print $var;

What I was reacting to was the claim that '1 + 2 + 3' was always
better than "1 + 2 + 3", which was backed up by a claim that this was
stated in the Perl documentation. I'd like to know which bit. I can't
recall ever seeing this in the documentation, but then, there have
been many changes made in the last year or so that I'm probably not
aware of.

Martien

 

[Uri Guttman]

MV> On Wed, 07 Jan 2004 17:40:54 GMT,
MV> And that's fine. But I object to just telling people "Don't use double
MV> quotes when single quotes would do just as well", especially when it's
MV> made more "authoritative" by invoking "the Perl documentation".
MV> I didn't mean that you calimed it. But this part of the thread started
MV> at a post in which someone (I'm too lazy now to look it up) did claim
MV> that the Perl documentation stated that you shouldn't use double
MV> quotes when single quotes suffice. Since I've never noticed that
MV> entry, I was wondering where it was, and when it was added.

oh, i didn't mean to say you accused me of claiming that. i just wanted
to make my position known as a (correct style point.

MV> It is, after all, a style issue, and not one of correctness.
MV> I see the smiley, but I still don't agree .

foo on you!

uri

 

[Tore Aursand]

That explains why you shouldn't quote variables with double quotes when
_no quotes_ would achieve the same thing. In other words, it discusses
things like [...]

Valid point, and I see now that I was a bit hasty with my comment. On a
personal basis, however, I would strongly suggest programmers to avoid
double qoutes when single quotes do the job.

Performance is one thing (single quotes are faster), but readability is
another thing; Personally, when browsing through some code, I must stop
and read variables with double quotes extra carefully to find out if
there's "something with/in them".

Seeing only single quotes - "ah, just another plain string".

You're right, however, that the part of the documentation that I quoted is
irrelevant in this case. Personally, I hope this is discussed in
perlstyle (which I haven't read for a while) or some other place in the
documentation.