Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Perl best practices fanatism

by cosimo (Hermit)
on Dec 08, 2007 at 21:14 UTC ( #655882=perlmeditation: print w/ replies, xml ) Need Help??

Ok, we all know and love the Perl Best Practices book. I wanted to say it before going on.

For the last 10 years I've been the lead developer of a large-scale web application written from scratch in Perl with more than 500,000 sloc according to David Wheeler's sloccount. Thanks Dave.

Recently I started with a new exciting job. And I met people there who do "whatever PBP says". And maybe this is because of their little or no experience and they just want to do "the right thing".

I mean, it's written in the book too, you should take these as best practices. You can agree or not. Of course, they are not meant as religion dogmas. If you have been programming for years, most of the book should be just natural for you.

And what I see instead is that many developers take those exactly as commandments, even if they go completely against the current codebase and guidelines. Just makes no sense.

Also, about Perl::Critic. It's ok and nice, but what's the point of polluting your code with ## no critics here and there? Probably would be better to write your own Perl::Critic::Policy then.

"So, what?"

Nothing special. If any of you had the same experiences, just drop me a note sharing your thoughts. Thank you, fellow monks.

Comment on Perl best practices fanatism
Select or Download Code
Re: Perl best practices fanatism
by merlyn (Sage) on Dec 08, 2007 at 21:29 UTC
    In my "PBP" talk, I have a number of slides that include the keywords "Damian says:" followed by "HOWEVER...".

    I think PBP is a great starting point if you don't want to do any thinking. I would hope that you want to do some thinking when designing your own style guide and practices, however.

      I think PBP is a great starting point if you don't want to do any thinking.
      actually this book made me think. it says clearly that the "rules" are just suggestions but that you should think about them and whether you follow them or not, you should think about why.
        The book looks like the most prominent Java books - do this, do that. The main question IMHO is why and not how.


      I think PBP is a great starting point if you don't want to do any thinking.

      There's so much to chew on in one little sentence. I think the odds are slim that a person would even glance at a book like PBP if they don't want to do any thinking. It's not one of those pocket guides that give you a summarized list without so much as a "how do you do." There is no starting point for a person who doesn't want to do any thinking. Well, there is: not thinking. That's also the stopping point.

      Of course PBP is not the final word. It does give a lot of guidelines along with a lengthy explanation of why Damian likes each one. I don't follow all of those guidelines. Heck, I don't even think I follow half of them. I chose not to take it as a list of commandments, though. It's just a collection of what Damian likes best.

      The book did make me think a lot about why I follow the practices I do and how I could improve on them, though. It seems to me that the book was a good starting point for somebody who wants to do a lot of thinking.

      That reminds me. Is there any hope for a second edition of "Effective Perl Programming"? That was a pretty handy book.

Re: Perl best practices fanatism
by CountZero (Bishop) on Dec 08, 2007 at 21:59 UTC
    Fanatism or fundamentalism should never be seen as a replacement for your own thinking processes.

    It are only those of small faith who must seek comfort in the rulings of others.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: Perl best practices fanatism
by brian_d_foy (Abbot) on Dec 08, 2007 at 22:02 UTC

    My interview with Damian Conway for The Perl Review speaks to a lot of these concerns. One of my favorite answers is to my question where I ask him if best practices for an individual can change as they get more experience. You'll have to read the interview to see what he says. :)

    Besides that, I think people must skip the preface and introduction. Damian lays out the mindset he thinks developers should be in to use his best practices and make sense of their coding.

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
Re: Perl best practices fanatism
by grep (Monsignor) on Dec 08, 2007 at 22:23 UTC
    If any of you had the same experiences, just drop me a note sharing your thoughts.
    I don't have the same experience, but I hope you don't mind me dropping a note ;)

    Having a standard is an effective form of communication when you are dealing a diverse (time or space) membership working in the same problem space. It's saves time, saves effort, and improves communication.

    Think traffic laws - they are a set of standards that allow you to know what the driver next to you should do. If those standards weren't there it would difficult to drive, you would have to graft on other forms of communication like hand signals, or curse words to drive safely. What makes them work (when people follow them) is they are reasonable (at least most are), there are not a lot of objections to them, and they are codified and easily obtainable.

    PBP is a reasonable set of rules, the community as a whole doesn't have a lot of objections, and it's codified in a nice package, so employing it as a standard makes a lot of sense. It saves time, improves communication, and prevents drunk coding accidents.

    That being said, PBP is not the be all end all nor should it be followed blindly, but as set coding standards it has a lot going for it. If PBP (or a subset of it) stops making sense in your organization then don't use it.

    grep
    One dead unjugged rabbit fish later...
Re: Perl best practices fanatism
by perrin (Chancellor) on Dec 09, 2007 at 01:02 UTC
    My experience has been that very few programmers try to follow anything as clearly defined as PBP, and with Perl you're generally lucky just to find a place where everyone turns on strict and warnings. You may chafe at some of the PBP stuff, but compared to the utter chaos that reigns in most programming teams I think you should count your blessings.
Re: Perl best practices fanatism
by chromatic (Archbishop) on Dec 09, 2007 at 02:05 UTC

    I like Perl::Critic, but once in a while I run across a policy that's completely wrong. My personal example today is the one to prohibit conditionals in declarations. That's right for lexicals, because of the unwarned and almost always entirely unwanted pseudo-static behavior exhibited through Perl 5.8... but the policy bafflingly warns about the construct for local variables, which do not exhibit this problem at all.

    If I could remember the name of the policy, I'd file a bug against it.

      It's Perl::Critic::Policy::Variables::ProhibitConditionalDeclarations. I remember because I requested it. I've never heard of this exception for local though. What's the story?

        I have testing code (Parrot::Test, for example) that sometimes needs to mark a test as TODO, but for various reasons can't set the appropriate package variable. In the case of Parrot, this is because the code being tested is not Perl. Thus the library contains a line something like:

        local ${ $package . '::TODO' } = $opts{todo} if $opts{todo};

        This construct is very different than the conditional declaration of a lexical variable because local only controls the visibility of a symbol's binding. The unbinding always occurs at the end of the scope if the conditional is true. Unlike lexical bindings, the false condition does not interfere with unbinding.

        xdg is right, and it does appear fixed. Nice!

      I already reported that bug and it was (supposedly) fixed in 1.079_001.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: Perl best practices fanatism
by swampyankee (Parson) on Dec 09, 2007 at 02:32 UTC

    I'm aware of but not very familiar with PBP. I'm also aware of some rather bizarre corporate programming rules, including forbidding indentation, requiring subroutines to fit on a single page of printout (about 60 lines), and even one requiring code to fit on one VDT screen (80 columns by 25 lines).

    One thing I would worry about is whether the "do whatever PBP says" are substituting the dicta of PBP for the intellectual judgment needed for code clarity and maintainability, which is, after all, the goal of coding standards. I doubt Dr Conway expects his book to be carved in stone, and its rules enforced by inquisitors (those not currently working at Guantanamo).


    emc

    Information about American English usage here and here.

    Any Northeastern US area jobs? I'm currently unemployed.

      The linux kernel coding standards says (amongst other good advice, some of which applies as well to Perl as C:

      Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

      I think it's generally right, if you go on to read the next two paragraphs:

      The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function.

      However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it than you would have done).

Re: Perl best practices fanatism
by dragonchild (Archbishop) on Dec 09, 2007 at 03:06 UTC
    I think of PBP in the same way as strictures. They're great starting points and, in the absence of any better ideas, it's usually good enough to get by. That said, I violate strictures all the time in my code. In very specific places, for very specific reasons. I do the same thing with PBP. I have my own set of best practices that have grown over the past dozen years and 15+ gigs. They're mostly the same as TheDamian's, but not quite.

    That said, I'd much rather a slavish adherence to PBP over a slavish adherence to no best practices (which I see from time to time).


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Perl best practices fanatism
by KurtSchwind (Hermit) on Dec 09, 2007 at 13:30 UTC

    I think we can all agree that PBP is a set of guidelines, not laws. But the guidelines are very good. If I was starting a new perl shop up, I'd hand that out as the guidelines to use. Like some other folks, I think it's far more common to have complete chaos and disorder than to have fanatical rule following.

    Given the two environments, I'd rather have the fanatics. But if I had the choice of working with people who thought about the rules and made conscience decisions to break them where appropriate (and Document those decisions), I'd rather have that.

    As it stands today, I try very hard to pass perlcritic -brutal if I can. I use strictures 99% of the time. But I don't get hung up if brutal is complaining about something I don't care about.

    --
    I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.
Re: Perl best practices fanatism
by tos (Deacon) on Dec 09, 2007 at 16:32 UTC
    PBP is quite remarkable, but in my opinion in some way it contradicts perl unwritten TIMTOWDI-law.

    As system administrator i'm in the confortable postion to use perl for my own, will say i have'nt regards for other programmers which have to understand my codings. Nevertheless it's in my own interest to write code which is qw/consise structured clear modular re-usable/ and neat.

    What i loves about perl mostly is it's undogmatic style. With perl i can "call a spade a spade" . I can write quickest and dirtiest one-liners and due to bash's history they can be used again and again.

    On the other hand i can build up big applications which use selfwritten or readymade modules. For better uptaking (?, ger: Begreifen) i like(d) to use "instruments" perl "has on bord" as far as usable. In young history i often prefer CPAN-modules, they are better than mine anyway and my laziness has grown.

    I read PBP partially and found it though a little bit dogmatic mainly interesting, especially the chapter "regular expressions". But when i came to the discourse about "inside-out" objects my interest faded because it acted as too "academically" to me. (Presumably i'm only to dumb for that.)

    Nevertheless my private o'reilly-zoo has meanwhile twelve exemplars. The book which brought the most benefit to me is, after the "Camel-Book", "Advanced Perl Programming" from Sriram Srinivasan.

    regards, Thomas


    Is simplicity best or simply the easiest Martin L. Gore
Re: Perl best practices fanatism
by mpeg4codec (Pilgrim) on Dec 10, 2007 at 02:22 UTC
    In the course of my Perl career, I went from complete and awful newbie (think Matt's Script Archive level) to being fairly competent. I was able to write maintainable, modular, and mostly visually appealing code. Unfortunately, being a broke high school student at the time, I couldn't afford PBP, so I never had an opportunity to ponder its advice.

    A few years ago, however, I had encouraged a coworker to learn Perl as a good general purpose scripting language. He bought the book during the endeavour, so I finally got my first look at it. I realised that probably something like 75% of the rules were things that I had independently discovered and already been doing, and the other 25% were mostly logical conclusions of the ones I already knew.

    My point is, many competent programmers will probably arrive at many of Damien's ``Best Practices''. I personally spent years to get to that point, and would have spent yet more troubling years to arrive at the last 25%. If I had read Conway's book from that start, it would have served as a good bootstrapping process and would have certainly saved me a lot of time and trouble, as it already has.

    Like most of you, I use the book as a reference and as sound advice. I don't agree with everything he's written, but most of his rules do have gems embedded in them, even if you don't agree with them.

Re: Perl best practices fanatism
by djp (Hermit) on Dec 10, 2007 at 02:56 UTC
    My shop (a dozen or so Perl developers of various levels of experience) adopted PBP in toto as the project coding standard shortly after it came out, precisely because it meant we didn't have to do any thinking. In this case, thinking costs money. Developing our own coding standards, based on PBP or something else, would have cost thousands, possibly tens of thousands of dollars - that's not what the project sponsor was paying us for. We just bypassed all the meetings, discussions and arguments about coding standards, and got stuck straight in to the actual project work. We use the excellent Perl::Critic in PBP mode to enforce adherence. The results have been excellent.

    For my next job, I hope to go somewehere that also adopts PBP as the coding standard. If not, I'll encourage them to adopt it. PBP may not be a perfect standard, but it's a very fine one, and with Perl::Critic it's ridiculously cheap and easy to adopt.

    +++ to Damian Conway and Jeffrey Thalhammer for making this possible.
Re: Perl best practices fanatism
by doom (Deacon) on Dec 10, 2007 at 03:20 UTC

    Almost any set of coding standards is better than none, and were I working for a boss that was a "Best Practices" fanatic, I would be overjoyed at having such an enlightened employer.

    That said, despite that fact that I like the book "Perl Best Practices" quite a bit (I've read it around three times now), once I've added up my questions and disagreements on each point, I personally would only recommend following around two-thirds of Damien's recommendations.

    Off the top of my head, a few disagreements:

    • He recommends his own Class::Std for doing inside-out objects, but it has problems with threads. Quinn Weaver of SF-perlmongers has been pushing Object::InsideOut, and I would probably try that first.
    • He seems to like source filters, and I definitely don't (I don't think that any one who uses the perl debugger would enjoy putting up with source filters). So every time he recommends a module, I need to check to see how it was implemented.
    • I like interspersed pod style (where each method has an "=item" accompanying the "sub" that explains how to use the method) -- it has it's problems, but overall I think it reduces the comments you need to write for a sub by supplying some verbal info in the form of documentation. I think his arguments for segregated pod boil down to personal taste (when he looks in a code file he wants to see code).
    • I have a number of differences on small stylistic issues, though the only one that comes to mind is that I think "unless" improves readability enough that you should use it instead of "if not", even though it's true that "if not" can sometimes make later edits eaisier.

Re: Perl best practices fanatism
by starX (Chaplain) on Dec 10, 2007 at 03:53 UTC
    Like the man said, "there's more than one way to do it."

    That being said, I like to aim for the following in my code:

    1) Functionality
    2) Readability
    3) Consistency

    And I look for them in that order. I suppose when I have a boss who disagrees with my methods, I may have to rethink them, but so far neither employer nor co worker has yet to take issue with the way I do things.

    I have to admit to not having sat down and read PBP yet (I've skimmed it), but that's largely because I was fortunate enough to have good CS profs who taught me to start by writing out step by step, in plain English, what I wanted to do and how I want to do it. It's amazing how big projects suddenly become a series of smaller, simple ones that way.

Re: Perl best practices fanatism
by talexb (Canon) on Dec 12, 2007 at 15:33 UTC

    Damian Conway is a brilliant guy, and he's hilarious to listen to. I can remember one visit to Toronto a few years back that was scheduled for something like two hours, and we ran over by .. two hours?

    The funny thing was, I could have sat there for another two hours and listened. It's just fantastic stuff.

    However .. I have read PBP as well, and while I agreed with a lot of what was in the book, I don't take it as gospel (reference intended) -- I agree with 90% of it, and usually I follow those recommendations. But I find it too intellectually jarring to conform exactly to what PBP says.

    It's almost like the dangerous discussion topic of top-posting and bottom-posting. Most of the time I bottom-post, but sometimes when a quick reply is request, I'll top-post. Or if I'm feeling keen, I'll do a really clean job of bottom-posting by re-formatting all of the previous layers.

    I don't use Perl::Critic -- my code is well-documented, and in some cases has really good test cases, but I'm the only one in my organization doing this kind of work (web application programming, socket programming, database programming) and I'm quite busy. The code works, it's clean, I'm around to support it. Enough.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Perl best practices fanatism
by ForgotPasswordAgain (Deacon) on Dec 12, 2007 at 15:41 UTC
    And what I see instead is that many developers take those exactly as commandments, even if they go completely against the current codebase and guidelines. Just makes no sense.

    It's probably their personality. Inflexible, need strict hierarchies where everyone's place is known, basically "fascist" or "autistic" or "would probably prefer Python".

Re: Perl best practices fanatism
by jnbek (Scribe) on Dec 12, 2007 at 18:31 UTC
    I personally find PBP and Perl::Critic invaluable as a learning tool. Now I don't follow each and every recommendation to the letter, it has helped me learn better programming practices, as I still have a long way to go before I'll be able to consider myself any kind of programmer. I tend to use q() and qq() alot in my code and perlcritic --brutal always seems to complain about it but I find it quicker than using \" or \' to me that makes my code harder to read and I'll tend to forget one somewhere and even with the syntax highlighting takes me sometimes forever to find it. There are a few other things I have found not applicable to the situation, such as it's insistence on using version control systems etc. I do my own work, it's 95% Web work, and i don't see the need to set up a subversion server just to keep track of a couple of scripts and a module or two. On the other hand though, I would say about 85% of the things I've learned from PBP have helped me as a beginner programmer immensely and would recommend it to anyone looking to learn Perl.
      not applicable to the situation, such as it's insistence on using version control
      It is interesting indeed to read others opinions. I started using a basic unix version control system (SCCS) more than 10 years ago, and have used RCS and CVS as well, every day of my life since. I find it to be such a crucial code development tool since it removes all fear from the process:
    • the fear of going down the wrong path,
    • the fear of commitment,
    • the fear of releasing bad code which is used by others
    • If I make a grave mistake, or even if I just hate what I churned out, retrieving the latest stable version takes mere seconds.

      In a way, I was a little surprised version control was even mentioned in the book, if only because I took it for granted that everyone used it as a matter of course. I learn something new everyday.

      There's no need to set up a server to use SVN. It will run perfectly well against a local repository on the same machine, or over ssh (again without a dedicated server) to a remote machine. And there's other options besides (or on top of :) SVN that don't require dedicated servers either.

      Additionally: Not that you're not free to work without a net if you really want to, just don't be surprised when you go splat. And you will eventually go splat (Murphy and what not . . .). And the more cautious who do use SCM religiously will snicker when you're hoist on your own petard.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

Re: Perl best practices fanatism
by Anonymous Monk on Jan 02, 2009 at 01:23 UTC
      I frequently come across some module or program that spends dozens of lines needlessly predeclaring variables.

      Got an example? By what criteria is it needless? Code evolves sometimes, sometimes defaults change, what you end up is with a lot of predeclaring, none of it is needless.

Re: Perl best practices fanatism
by Anonymous Monk on Jul 04, 2009 at 04:53 UTC
    I have to agree with the charge of fanaticism. Too many people think that PBP is the Bible, IMHO. It explains everything to them.

    I have been in interviews where if my answer to a question deviated slightly from something in PBP, my answer was deemed completely wrong. Why was it wrong? Because PBP said it was (according to the interviewer)! When I pointed out TIMTOWTDI, the interviewer looked lost. In other words, it seemed that their Perl knowledge was strictly limited to PBP.

    Now replace "PBP" with the "Holy Bible" in the previous paragraph and you will get my drift. One thing I have learned in interviews is to keep things simple if you suspect you know more than the interviewer. Otherwise, some people will dismiss you as a blasphemous heathen who doesn't know Conway's God's Laws.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://655882]
Approved by ww
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (17)
As of 2014-09-23 17:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (233 votes), past polls