Hello All, Thanks for all your answers, the reason i brought the question to mind, was that we have memory leaking somewhere that makes our server goes to 100% usage, and thought that might Perl be the one to be blamed, when using tooooo many of 'quotes' that might make Perl be out-resourced. Will need to check for other things, like DB connections, forks not needed....:-(
Many thanks chanan On Fri, Feb 4, 2011 at 1:59 PM, Shlomi Fish <shlo...@iglu.org.il> wrote: > 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 >> Perl@perl.org.il >> 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 > Perl@perl.org.il > http://mail.perl.org.il/mailman/listinfo/perl > -- =================== ---- Chanan Berler ---- =================== _______________________________________________ Perl mailing list Perl@perl.org.il http://mail.perl.org.il/mailman/listinfo/perl
