On Friday 04 Feb 2011 12:16:56 Offer Kaye wrote: > On Fri, Feb 4, 2011 at 8:12 AM, Gabor Szabo wrote: > > Style > > ====== > > Regarding style I am not sure leaving out the quotes is the "better way". > > http://stackoverflow.com/questions/401556/are-quotes-around-hash-keys-a-goo > d-practice-in-perl >
Sorry for breaking the link - it was OK in the original message. > In StackOverflow where this question was asked, the highest rated > answer was to quote keys. The reason which was given was much the same > as the one Gabor gave, to preserve consistency in the case of keys > containing spaces or other similar cases. > > It's too bad there isn't a Perl::Critic policy for this. > > Perl::Tidy also doesn't deal with this issue, in fact you can find > both quoted and unquoted code examples in the style guide at: > http://search.cpan.org/dist/Perl-Tidy/docs/stylekey.pod > Well, my feeling about this is that either way is OK. I used to religiously stick to $self->{'slot'} or maybe even $self->{"slot"} and was happy, and then started writing $self->{slot} out of laziness. Of course, if your keys get out of hand, consider extracting a class and using accessors which is much safer. As chromatic and I noted here: http://www.modernperlbooks.com/mt/2009/10/from-novice-to-adept-embracing- idioms.html (broken link ; short link - http://xrl.us/bihbay ). Beginners often tend to become confused by colour of the bike shed arguments like that, where the arguments pro and against each viewpoint have some small technical merit, but as a general rule are a matter of taste. chromatic later expanded on it: http://www.modernperlbooks.com/mt/2009/10/from-novice-to-adept-on-answers-to- smart-questions.html (broken link ; short link - http://xrl.us/bihbcf ). I should note that we were preceded (although on a more trivial issue) of this focus by Joel Spolsky: http://www.joelonsoftware.com/articles/Wrong.html - "Making the Wrong Code Look Wrong" [1] He explains there why trying to enforce a consistent style across the application, and spending many days making it confirm to this style (barring automatic formatters such as GNU indent or perltidy or insert-your-favourite- editor-or-IDE-'s-formatting-function), is kinda a waste of time. [footnotes] [1] - I have some reservation regarding the theme of the article, in which I feel that while the wrong code should look wrong, in an ideal language (and, for better or worse, the languages we often have to use are not ideal) the wrong code will behave wrong. Joel gives giving variables prefixes like "escaped" or "unescaped" (Hungarian notation) for preventing HTML injection attacks is a good idea, but I feel that with the ideal type/kind system an unescaped variable won't be able to be emitted into the HTML stream in the first place, which is the approach taken by http://www.impredicative.com/ur/ . Furthermore, I prefer to throw exceptions because if something bad happens, I want my code to crash, burn and kill my dog rather than just return an error code which I'm likely going to avoid. [/footnotes] In any case, Chanan (and everybody) should know that both of these syntaxes are equivalent in case the enclosed string is a bareword, and that one of them may have an incredibly small compile-time penalty (which won't become apparent unless one does an excessive amount of string evals, which is usually an exceptionally bad idea , especially for this use-case), and that he can pick up his own style, or change it. This is one of Perl's TIMTOWTDYISMS. In addition , it is important that people who learn Perl know that both styles are possible and when they are equivalent or different, because this would be important for reading and modifying other people's code. This is similar to the fact that we should introduce them to backward Perl idioms (e.g: http://perl-begin.org/tutorials/bad-elements/ or PBP), so they can tell what they do and rewrite them, only that in this case neither $self->{slot} nor $self->{'slot'} are conclusively considered ancient Perl, so it's even more important to recognise them and either convert them to the factory's style or let them be. Such inconsistencies in matters of style are especailly prevalent in the Perl 5 language due to its richness and "There is more than one way to do it philosophy" but they exist in many other languages too (most languages?). My opinion is that it's not worth a lot to waste one's energy on this. Hakunah Matatah. Regards, Shlomi Fish > Maybe it's a Touchy Subject! :) > > Regards, > Offer Kaye > _______________________________________________ > Perl mailing list > [email protected] > http://mail.perl.org.il/mailman/listinfo/perl -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Optimising Code for Speed - http://shlom.in/optimise Chuck Norris can make the statement "This statement is false" a true one. Please reply to list if it's a mailing list post - http://shlom.in/reply . _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
