http://www.perlmonks.org?node_id=805549


in reply to Re: RFC: Creating unicursal stars
in thread RFC: Creating unicursal stars

There is a really good template at (tye)Re: Stupid question

Replies are listed 'Best First'.
Re^3: RFC: Creating unicursal stars
by Your Mother (Archbishop) on Nov 07, 2009 at 16:54 UTC

    That template is from 2000 (we're three versions of Perl past that time), was probably mostly developed even earlier, and while tye's advice is generally to be preferred over mine, I would call camelCase bad—or at the most defensible least, uncommon—Perl style.

      To be fair, Your Mother is from before 2000 (though I don't recall using Perl v2 that year) and was probably conceived even before that. That is clearly enough reason to discount something with no further justificaiton. Oh, wait, I forgot to make a dubious style argument. Unfortunately, most have not seen how he dresses, so I'll omit that. (:

      was probably mostly developed even earlier

      Perhaps you are unfamiliar with the meaning of the words "updated" and "update"?

      Actually, much (I'm not sure "most") originated before 2000. And I've updated it quite recently (and several times before that) and so anything from before 2000 must be some of the best of that style since it has survived unchanged for so long.

      So, did you actually have any real critique to offer (other than the one style point)? I'm sure people would love to learn what can be improved and how (and why).

      As to CamelCase, I'll disagree that it is bad and also that it is uncommon in Perl. I seriously doubt you are using the modules file_handle, ext_utils::make_maker, dyna_loader, auto_loader, math::big_int, or time::hi_res to name just a tiny fraction. And the motivations for using CamelCase in module names at least partly matches my motivations for using it in subroutine names.

      Compare the output of perl -we "print this" vs. perl -we "print This" and you'll see that the second avoids:

      Unquoted string "this" may clash with future reserved word

      Unfortunately, it seems that most Perl guides pretty much ignore the problems with the following code:

      sub log { warn timestamp(), "@_"; } sub dump { log( Dumper( \@_ ) ); }

      I expect a significant fraction of serious Perl coders to notice the problem with line 1 (I'm not sure if it would be more or less than half of them). I expect only a small fraction to notice the problem with line 5. I expect many to go so far as to deny the problem with line 2.

      Personally, I much prefer a style that simply prevents all of those problems. Which means I updated my standard template to not use "sub main". The two routes I considered were CamelCase and under_scored. under_scored would have meant either "sub _main" or "sub main_" and the former of those already is well-established style for "private" and so would be quite confusing while the latter I consider rather silly looking and much, much more unusual than "sub Main", which is what I standardized on. (And going with "sub Main" with the intent of keeping underscores would lead to the Under_Scored_Capitalized style which I find rather "the worst of both worlds".)

      I don't personally grumble when I run into under_scored-style identifiers in Perl code (much less go publicly proclaiming such to be "bad"). But I do dislike the relative difficulty of typing _, that fact that documentation about such identifiers usually ends up with the _ being wider than whitespace and thus the spacing conveys rather the opposite of what _ is meant to convey, and that things like HTML links often make such style very hard_to read with_confidence. While I almost never run into identifiers that get to the point of being difficult to read whenWrittenInCamelCase (and can't think of any other down sides to camelCase). So I personally consider CamelCase to be slightly better than under_scored in several ways and worse than under_scored in no practical ways. But I end up using both under_scored and CamelCase quite a bit in Perl code.

      But, of coure, the point of that template has extremely little to do with what style one uses for their variable names. I really don't want anybody to declare a lexical with the name $putMainVarsHere.

      As for some more "modern" alternatives, I actually prefer -w over warnings.pm for this specific case (and prefer neither for writing modules), though I do value and use warnings.pm in much more limited scenarios (but I won't go into the "why"s in this node -- though I have discussed at least much of that elsewhere around here).

      I often prefer use vars over our, especially in modules. But I do use our when it is worth it. I'm probably even more likely to replace use vars qw( $Globals ); in that template with my $Global= ...;. But the distinction between any of those three choices isn't the point of that terse example, either.

      Then there are state variables. A great many of the Perl installs that I use right now don't support such. It certainly isn't time for me to consider standardizing on using them. Nor do I believe that I'd always replace my current pattern even when state $x is an option. Actually, the next module I'll be putting on CPAN (perhaps this week) deals with this type of stuff.

      - tye        

        I'll preface by repeating, your advice is generally to be preferred over mine. I know what an excellent hacker and thinker you are. That you got snarky and got the version stuff wrong in your rush to put me in my place makes me think this particular topic is personal to you. It's not to me.

        So, did you actually have any real critique to offer (other than the one style point)? I'm sure people would love to learn what can be improved and how (and why).

        I was responding to the assertion that it was an excellent template to be emulated or used by anyone. To me, style-wise, it reads like a C-hacker's impression of perl 5.4. Which is fine. I just personally find it jarring and wouldn't recommend it.

        #!/usr/bin/env perl is a nice idiom which I think is better than the one you use and I used to. It would have saved me a lot of headaches earlier this year if I had been using the env trick all along.

        Putting in a piece of boiler plate which serves (mostly?) to help Apache::Registry which is as I understand it, a shim to give one time to get one's code correctly setup for modperl seems like a mistake.

        The part I see in there that might have saved me headaches in my own stuff is the Main(@ARGV) but I think that has more to do with me misunderstanding ARGV for a long time than anything else.

        Someone has notched up the "error" output of one of my modules by turning on $^W in one of the dependencies (and displaying tons of harmless warnings about yet another dependency, not my code). I think it's great for development. I don't think you should do things that cause secondary effects in other code for production.

        The fact that you end up using camel and underscores together sort of underscores my point that it's bad style. I see the issue it "saves" you from. I have never hit it. I think the last time we had this discussion your justification was that it was necessary because of CGI::Tr. If you really see the "reserved word" as a serious problem, patching perl might be a better idea. I never saw the message before because I either use strict or call subs with more explicit syntax.

        Regarding updates: if it's meant to be a living doc, it shouldn't be in a SoPW reply where the updates are not dated and the piece itself says the code is older than 2000.

        (though I don't recall using Perl v2 that year)

        Versions, not revisions. Not counting development releases, the three versions of Perl since 2000 are 5.6, 5.8, 5.10.

        #define PERL_REVISION 5 /* age */ #define PERL_VERSION 6 /* epoch */ #define PERL_SUBVERSION 2 /* generation */
      I've used that template about 10 times in the past month and it helped me avoid the pitfalls tye lists as justifications at least 5 times. To use your words Your Mother, And we were just discussing Dunning–Kruger the other day...

        Here's some more words you can reuse: Cargo-culting is a normal phase in the development of the novice hacker.