|
Re: Optional quotes: to use or not to
by hippo (Archbishop) on Jul 10, 2015 at 10:57 UTC
|
are you using quotes in such situations?
No.
why?
The quotes add little value.
pros of your way
Less typing, less clutter, shorter lines. Forces the programmer to use restricted characters in key names.
cons of your way
Forces the programmer to use restricted characters in key names. :-)
It's all a matter of personal choice. Feel free to choose either way. Just be consistent. .
| [reply] |
|
|
| [reply] |
Re: Optional quotes: to use or not to (fewer ways)
by tye (Sage) on Jul 10, 2015 at 17:47 UTC
|
Our $work style guide says to use no quotes and no spaces for such hash keys because it is easier to search for {word} than for any of {word}, { word }, {"word"}, {'word'}, and some more obscure styles of quoting. Similarly, you can search for /\bword\s*=>/ more easily than trying to guess what type of quoting might be used; and adding quotes means somebody might not have even used =>.
On rare occasions, you have a mix of bareword keys and keys with hyphens or dots and have to mix: word => $word, 'non-word' => $non_word. But I have not found that to be a disadvantage.
Of course, the advantage is fairly minor in the scheme of things.
Then there is the idea of avoiding retyping such key names where a typo won't be caught for you and so you define constants for your keys and end up with $WORD => $word or WORD() => $word. Or just avoid using a hash and use separate variables (especially for command-line options).
| [reply]
[d/l]
[select] |
Re: Optional quotes: to use or not to
by Monk::Thomas (Friar) on Jul 10, 2015 at 11:23 UTC
|
my $abc = { 'word' => 'abc', 'number' => 123};
$abc->{'otherword'} = 345;
Always for strings, never for numerical values.
why? / pros of your way
Visually distinct from other stuff, syntax highlight treats quoted values differently -> easier to recognize if something looks strange.
cons of your way
It's not necessary to quote everything.
| [reply]
[d/l] |
|
|
Visually distinct from other stuff, syntax highlight treats quoted values differently -> easier to recognize if something looks strange.
Well, this depends on IDE you are using
| [reply] |
|
|
$example{time} = time;
Does your IDE get that right? What exactly is 'right'?
| [reply] |
|
|
|
|
|
|
|
I'm returning to this post because the other one's have strayed off. Sorry about that.
What I originally meant to say is, that I like string values to be shown in exactly the same way wherever they are located. If I use quotes to denote them then this is guaranteed.
You were asking about a team and that means it's possible the members are using different IDE's / editors. If the coding convention makes it easier to look over one's shoulder and see roughly the same patterns in syntax-highlighted code then that's a win in my book. (It doesn't really matter what the actual colors are, the pattern is important.)
| [reply] |
Re: Optional quotes: to use or not to
by trippledubs (Deacon) on Jul 10, 2015 at 16:51 UTC
|
Keep your Perl looking sexy and avoid them at all costs
my %hash;
my $string='123132877\'863246234*^&*@#^$^@#%$#%@$@';
$hash{neverUseQuotes} = 1;
$hash{$string} = 1;
$hash{q(This is a dumb key)} = 1;
The exception: back quotes
@hash{`find nits`} = 1;
Possibly just idiosyncratic from the way you learn it first | [reply]
[d/l]
[select] |
Re: Optional quotes: to use or not to
by u65 (Chaplain) on Jul 10, 2015 at 11:16 UTC
|
Note that bare words aren't allowed inside hash curlies in Perl 6 so using quotes would be sort of future proofing that part of your code.
| [reply] |
|
|
$ perl6 -e'my %h = foo => 1; %h.perl.say'
{:foo(1)}<>
$ perl6 -e'my %h; %h<foo> = 1; %h.perl.say'
{:foo(1)}<>
FWIW I do not use quotes whenever possible.
When I use quotes, I use double quotes. always.
I put all keys of a hash inside quotes in an initialization when any of the keys need quotation, for consistency and visual appealing.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l] |
|
|
print 'The value of $scalar is ', $scalar, ', and this line ends with
+\n', "\n";
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply]
[d/l] |
|
|
|
|
Well, nice argument, but, Perl6 is a pretty different language at first, and in few years I doubt someone will willingly migrate any serious project from Perl5 to Perl6 because of long born, performance issues and unclear future.
The point is that other languages does not allow this, I know.
| [reply] |
Re: Optional quotes: to use or not to
by locked_user sundialsvc4 (Abbot) on Jul 10, 2015 at 12:21 UTC
|
Whereas my own viewpoint would be quite definite: “never use barewords!”
A bareword is a string literal that doesn’t look like one. I believe very strongly that everything in the source-code of a computer program should look, to a human being, like what it actually is to the compiler. If that means typing two extra characters and pressing the Shift key twice, c’est la guerre. We aren’t putting source code on paper tape anymore.
Now, let me tell you why. Remember, from my Meditations thread, that “I see dead projects.” The software was abandoned by a programmer or team that did very sloppy, unsupervised work, e.g. before their visa-time ran out. In one such case, many days were spent looking for what turned out to be ... “an omitted dollar-sign.” foo instead of $foo, buried deeply in a mountain of shit source code. A bareword, meant to be a variable-reference, but acceptable to the Perl compiler.
Unlike most other languages today (JavaScript being the most notable and therefore most egregious exception), Perl is very permissive. It likes to assume that you meant exactly what you say, that you never make a tpyographic error, never use the wring word, put never words in the order wrong. That source is meant to be taken at face-value exactly as writ, if possible. The defense against this is coding-standards, and to me this is an important one.
| |
|
|
foo instead of $foo, buried deeply in a mountain of shit source code. A bareword, meant to be a variable-reference, but acceptable to the Perl compiler.
How would "the Perl compiler" accept 'foo' as a bareword if you were using strict and/or warnings? Couldn't you find the problem immediately if you turned those on?
#! perl
# 1134136.pl
use strict;
my ($bottom, $top);
my @mountain = ($bottom, $top, foo);
exit;
[05:38][nick:~/monks]$ perl 1134136.pl
Bareword "foo" not allowed while "strict subs" in use at 1134136.pl li
+ne 4.
Execution of 1134136.pl aborted due to compilation errors.
#! perl
# 1134136-2.pl
use warnings;
my ($bottom, $top);
my @mountain = ($bottom, $top, foo);
exit;
[05:41][nick:~/monks]$ perl 1134136-2.pl
Unquoted string "foo" may clash with future reserved word at 1134136-2
+.pl line 5.
Remember: Ne dederis in spiritu molere illegitimi!
| [reply]
[d/l]
[select] |
|
|
my %h;
$h{foo} = 82;
| [reply]
[d/l] |
|
|
| [reply] |