in reply to Idiom for a regex translation
... I'm forced to initially assign it with a value that clearly isn't squished. In fact, 'don't like' isn't close, I really hate bad variables names.I agree with you with the genaral idea (calling the variable $another_form_for_name would be bad), but not in the application in this particular case: you're adjusting the value on the very following line, so I don't think that your assignment breaks any understandability in the code. At last, using good variable names is all about readability and understandability, isn't it?
Probably you're happy with the previous answers, but probably you're just because your variable lives some instants in which it holds data that do not match the semantic you assign to the variable. If this is the case (skip the following if it's not, of course), the particular problem seems that you want to assign a static/fixed semantic to the variable, declared by its name. This seems near to a contradiction-in-terms, just because it's a variable, and variables should be meant to evolve during their life. You can stick with this:
just to be sure that $squished_name won't ever contain a non-squished value, but does it add value to the code or does it make the code harder to read?my $name = "Rob J Anderson"; (my $tmp_for_squishing = $name) =~ s/\W//g; my $squished_name = $tmp_for_squishing;
The general answer I received to my paranoid post can be boiled down to this: as long as the program is readable, maintainable, correct and does its job in the correct time... don't waste time on these time-consuming issues!
(1)Testing at the right granularity and Writing general code: real world example - and doubts! for a few examples of my level of paranoid.
Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')
Don't fool yourself.
|
|---|