perlstyles

[Matija Papec]

I was wandering what would be more readable for code maintainers, I prefer
first as it's far more obvious what's going on(not to mention typing
laziness), but that's just me.

#1
@arr = join ',', map s|'|\\'|g && "'$_'", grep /^MB/, @arr;
#2
@arr = join(',', map(s|'|\\'|g && "'$_'", grep(/^MB/, @arr)));

and another one, how do you prefer $h{key} over $h{'key'} in case where key
is strictly English \w class?

Most importantly, what would you tell to someone who doesn't have a clue
about use strict and warnings, and at the same time insisting on quoted hash
keys?

 

[Uri Guttman]

MP> I was wandering what would be more readable for code maintainers,
MP> I prefer first as it's far more obvious what's going on(not to
MP> mention typing laziness), but that's just me.

MP> #1
MP> @arr = join ',', map s|'|\\'|g && "'$_'", grep /^MB/, @arr;
MP> #2
MP> @arr = join(',', map(s|'|\\'|g && "'$_'", grep(/^MB/, @arr)));

when using nested stuff like that, i usually prefer parens to help
out. but i am not strict about it. it may depend subtly on the actual
code and my mood.

MP> and another one, how do you prefer $h{key} over $h{'key'} in case
MP> where key is strictly English \w class?

i prefer quotes all the time for fixed string hash keys. combination of
old habit and being cautious. i have seen issues where a key was also a
function name and with quotes you know which one it is (even if it works
the way you want).

MP> Most importantly, what would you tell to someone who doesn't have
MP> a clue about use strict and warnings, and at the same time
MP> insisting on quoted hash keys?

that is another matter and i don't know the person. the size of the
cluebat you use will be critical.

uri

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

MP> and another one, how do you prefer $h{key} over $h{'key'} in case
MP> where key is strictly English \w class?

i prefer quotes all the time for fixed string hash keys. combination of
old habit and being cautious. i have seen issues where a key was also a
function name and with quotes you know which one it is (even if it works
the way you want).

Is that a problem actually? I tend to have problems with the opposite
case: Where something is meant to be a keyword but perl treats it as a
string, as in

$hash{ shift } = 1;

That leads to some contortions like

$hash{ +shift } = 1;

etc.

I've lately come to use quotes, too. My reason is the syntax-highlighter
of vim that marks hash-keys in the same color as strings only when they
are enclosed in some pair of quotation marks. Otherwise they wont get
colored at all.

Tassilo

 

[Steven Kuo]

On 17 Jul 2003, Tassilo v. Parseval wrote:

....

Is that a problem actually? I tend to have problems with the opposite
case: Where something is meant to be a keyword but perl treats it as a
string, as in

$hash{ shift } = 1;

That leads to some contortions like

$hash{ +shift } = 1;

etc.

I've lately come to use quotes, too. My reason is the syntax-highlighter
of vim that marks hash-keys in the same color as strings only when they
are enclosed in some pair of quotation marks. Otherwise they wont get
colored at all.

I also quote hash keys after having encountered the dreaded
'vstring':

my %hash = (
t10 => 'Tiger',
t20 => 'Turtle',
u10 => 'Urchin',
v10 => 'Viper', # !! does not quote LHS of => !!
);

print keys %hash;

 

[Janek Schleicher]

parv wrote at Fri, 18 Jul 2003 03:14:08 +0000:

In this case, i would like to show that the output place is same as
input (use of map/grep BLOCK is intentional to avoid distracting
commas & parentheses)...

@arr = join ',' , map { s/'/\\'/g; "'$_'" }

^^

That is very different from the OP's &&.
In your solution, every element of the array is mapped into enclosing
single quotes, while in the OP's code, an element is only enclosed by
single quotes if there had been any single quote inside the element
before.
I don't know whether it is a problem for the OP, but at least, it's a
little difference

grep { /^MB/ }
@arr;

Greetings,
Janek

 

[Janek Schleicher]

Matija Papec wrote at Thu, 17 Jul 2003 22:27:08 +0200:

I was wandering what would be more readable for code maintainers, I prefer
first as it's far more obvious what's going on(not to mention typing
laziness), but that's just me.

#1
@arr = join ',', map s|'|\\'|g && "'$_'", grep /^MB/, @arr;

^^^^ ^^^^

An array
result is a string!

#2
@arr = join(',', map(s|'|\\'|g && "'$_'", grep(/^MB/, @arr)));

I wouldn't look so much to the brackets regarding for code maintainers.
It is easy and simple to understand that both lines
do a comma-join over all transformed elements of @arr that starts with MB.

What is hard to understand on the first view is the transformation that
has to be done. You first need to think some seconds only to comprehend it. And
even if you did it, you can't be sure whether the implemented algorithm
was also the intended one. That is dangerous for maintainance.

I think it would be better to write a subroutine doing exactly this
transformation. If the subroutine has a sensful name, the maintainer can
read and understand without any thinking what the line does. In addition,
he/she can decide whether the transformation does what the subroutine name
says or a completely different transformation will be needed instead.

Let's say something like:

sub escape_single_quotes($) {
my $string = shift;
$string =~ s,',\\',g
and return qq/'$string'/
or return $string;
}

my $str = join ",", map escape_single_quotes($_), grep /^MB/, @arr;


Note, that I also did two other slight changes.
First I changed the pipe symbol to a comma in the substitution.
Not that the comma is so much better, but IMHO the pipe is that worse,
as it is also the alternation operator with such a special meaning in
substitutions, that it is very confusing (and thus less readable) if it
is used as delimiters in regexps.
Second I wrote "'$string'" as qq/'$string'/. I wanted to emphasize that
the returned value is in principle the '$string' in contrast to the simple
$string. I prefer not to have "' or '" in a text as single and double
quotes look similar and are hard to distinguish if they are very near in
the next. (But that's perhaps more a personal style than a hard
maintainance demand)

and another one, how do you prefer $h{key} over $h{'key'} in case where key
is strictly English \w class?

Both doesn't matter for readability and maintainance. I, personally, wouldn't write
$h{'key'} where it isn't necessary (main reason is laziness),
but both ways are easy to read, understand and change.

Most importantly, what would you tell to someone who doesn't have a clue
about use strict and warnings, and at the same time insisting on quoted hash
keys?

Who has no clue about strict and warnings, should not maintain my code!


Greetings,
Janek

 

[Eric Moors]

my %hash = (
t10 => 'Tiger',
t20 => 'Turtle',
u10 => 'Urchin',
v10 => 'Viper', # !! does not quote LHS of => !!
);

print keys %hash;

Why is this?
I couldn't find anyting about it with perldoc.

Eric

 

[Jay Tilton]

: On Fri, 18 Jul 2003 01:02:46 +0200, Steven Kuo wrote:
:
: > my %hash = (
: > t10 => 'Tiger',
: > t20 => 'Turtle',
: > u10 => 'Urchin',
: > v10 => 'Viper', # !! does not quote LHS of => !!
: > );
: >
: > print keys %hash;
:
: Why is this?
: I couldn't find anyting about it with perldoc.

See perldata. Scan for "v-strings".

 

[Matija Papec]

X-Ftn-To: Uri Guttman

MP> I prefer first as it's far more obvious what's going on(not to
MP> mention typing laziness), but that's just me.

MP> #1
MP> @arr = join ',', map s|'|\\'|g && "'$_'", grep /^MB/, @arr;
MP> #2
MP> @arr = join(',', map(s|'|\\'|g && "'$_'", grep(/^MB/, @arr)));

when using nested stuff like that, i usually prefer parens to help
out. but i am not strict about it. it may depend subtly on the actual
code and my mood.

It appears to me that thinking in terms of 'chained lists' lead to faster
code understanding as opposed to nested thinking. For example,

$s = join ',',
map { s|'|\\'|g && "'$_'" }
grep { /^MB/ } @arr;

is very easy to follow from right/bottom to left/top, and if we add another
map and sort to it, it would still be easy on the eyes.

MP> and another one, how do you prefer $h{key} over $h{'key'} in case
MP> where key is strictly English \w class?

i prefer quotes all the time for fixed string hash keys. combination of
old habit and being cautious. i have seen issues where a key was also a
function name and with quotes you know which one it is (even if it works
the way you want).

Hm, under which circumstances is key interpreted as sub? I just tried,

sub key { return 'gotcha' }
$Q{key} = 11;
print join('=>', %Q), "\n";

and it prints 'key=>11'?

btw, is there some "use" clause which favores plain keys over subs with same
names?

MP> a clue about use strict and warnings, and at the same time
MP> insisting on quoted hash keys?

that is another matter and i don't know the person. the size of the
cluebat you use will be critical.

And I'm afraid, if all else fails one can always turn to more persuasive
kind of bats. <g>

 

[Matija Papec]

X-Ftn-To: parv

In this case, i would like to show that the output place is same as
input (use of map/grep BLOCK is intentional to avoid distracting
commas & parentheses)...

@arr = join ',' , map { s/'/\\'/g; "'$_'" }
grep { /^MB/ }
@arr;


Number & position of parentheses depends on what is being emphasized,
need to preserve order of execution, and grouping of pieces in a
larger expression. Example of the last criterion...

@arr =
join ',' , map ( s/'/\\'/g && "'$_'" ) , (grep ( /^MB/ ) , @arr);

(I maintain only my own code, what would i know.)



I used to use bare keys, but after the irritating error message about
usage of a key w/ a hyphen in its name, i use quoted keys w/o
exception.

That makes sense, but afaik you shouldn't have problems with
%h = (-foo => 'bar');
What is your perl version?

 

[Eric Moors]

: On Fri, 18 Jul 2003 01:02:46 +0200, Steven Kuo wrote:
:
: > my %hash = (
: > t10 => 'Tiger',
: > t20 => 'Turtle',
: > u10 => 'Urchin',
: > v10 => 'Viper', # !! does not quote LHS of => !!
: > );
: >
: > print keys %hash;
:
: Why is this?
: I couldn't find anyting about it with perldoc.

See perldata. Scan for "v-strings".

v-strings doesn't occur in the perldata manpage I have.
(searching for "version number" would have been a better hint)

But I found an explanation in my copy of "Programming Perl"
v10 gets transformed into newline.

Eric

 

[Michele Dondi]

I've lately come to use quotes, too. My reason is the syntax-highlighter
of vim that marks hash-keys in the same color as strings only when they
are enclosed in some pair of quotation marks. Otherwise they wont get
colored at all.

<OT>
What bothers me about *my* editor[*] is its inability to tell blocks
from inline hash refs, but then "only perl can parse Perl" and even
perl needs some help in certain circumstances.

A simple minded solution might be based upon assuming hash ref if the
construct goes like '{ key => something...', but I still don't have
the basic skills to edit my editor's perl mode and it doesn't seem
that other users are interested in this issue...
</OT>


[*] No, it is neither emacs nor vim, and not a dedicated IDE. It's
jed...


Michele

 

[Matija Papec]

X-Ftn-To: Janek Schleicher

^^^^ ^^^^

An array
result is a string!
Ack.


I wouldn't look so much to the brackets regarding for code maintainers.
It is easy and simple to understand that both lines
do a comma-join over all transformed elements of @arr that starts with MB.

What is hard to understand on the first view is the transformation that
has to be done. You first need to think some seconds only to comprehend it. And
even if you did it, you can't be sure whether the implemented algorithm
was also the intended one. That is dangerous for maintainance.

I think it would be better to write a subroutine doing exactly this
transformation. If the subroutine has a sensful name, the maintainer can
read and understand without any thinking what the line does. In addition,
he/she can decide whether the transformation does what the subroutine name
says or a completely different transformation will be needed instead.

Subroutine is ok, but I'll be rather using it in case when it's more complex
or if it's needed on more then one place in script. map with block braces
comes very handy here.

Let's say something like:

sub escape_single_quotes($) {
my $string = shift;
$string =~ s,',\\',g
and return qq/'$string'/
or return $string;
}

my $str = join ",", map escape_single_quotes($_), grep /^MB/, @arr;


Note, that I also did two other slight changes.
First I changed the pipe symbol to a comma in the substitution.
Not that the comma is so much better, but IMHO the pipe is that worse,
as it is also the alternation operator with such a special meaning in
substitutions, that it is very confusing (and thus less readable) if it
is used as delimiters in regexps.

I prefer ! or | as delimiters in simple regex as they stand vertical(that
depends mostly on which key is nearer to punch )

Second I wrote "'$string'" as qq/'$string'/. I wanted to emphasize that
the returned value is in principle the '$string' in contrast to the simple
$string. I prefer not to have "' or '" in a text as single and double
quotes look similar and are hard to distinguish if they are very near in
the next. (But that's perhaps more a personal style than a hard
maintainance demand)



Both doesn't matter for readability and maintainance. I, personally, wouldn't write
$h{'key'} where it isn't necessary (main reason is laziness),
but both ways are easy to read, understand and change.

Most of the time they are, but did you have a chance to see something like
this?

"sql stuff.. values ('$h{'key1'}','$h{'key2'}','$h{'key3'}',...)"