Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ajt (2546)

ajt
  (email not shown publicly)
http://www.iredale.net/

UK based. Perl, XML/HTTP, SAP, Debian hacker.

  • CPAN: ATRICKETT [cpan.org]
  • PerlMonks: ajt [perlmonks.org]
  • Local LUG: AdamTrickett [lug.org.uk]
  • Debian Administration: ajt [debian-adm...ration.org]
  • LinkedIn: drajt [linkedin.com]

Journal of ajt (2546)

Wednesday February 22, 2006
05:40 PM

Testing

[ #28780 ]

I got "The Damian"'s PBP last year. Since the start of this month I've been working over some older modules. I've been doing my best to bring them up to "best practices".

Using a combination of the book, Perl::Critic, Module::Build, Devel::Coverage, I've found several no-ops in the code and some subtle bugs that had gone undetected.

I've added loads of tests and currently the first modules I've been really working on is now upto 98.7%, 87.5%, 73.7%, 100%, 100%, 100% and 93% on the test coverage stats. I've got no severity 5 PBP issues, only two severity 4s that I can't fix without changing the API, and I've reduced the number of severity 1, 2 and 3 issues by over half.

I know that following guidelines isn't a panacea for good code, but it's been an interesting process that does force you to think about your code. Is it really okay to deviate from PBP or the guidelines really better? I've also found some bugs, so it's been well worth it.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Testing 12 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Is it really okay to deviate from PBP or the guidelines really better?

    Why wouldn't it be OK? Damian isn't omniscient. He's just one guy.

    I love the book, and yet I've submitted a talk proposal for OSCON about amending his guidelines.

    --

    --
    xoa

    • I am curious to know which ones you feel that strongly about that you would come up with an OSCON presentation about it.
      • Well, now, you'll just have to wait until OSCON and/or YAPC to find out! :-)
        --

        --
        xoa

        • Well, now, you'll just have to wait until OSCON and/or YAPC to find out! :-)

          Ok. I look forward to hearing it in either Birmingham or Brussels :)

          • It's all a dialogue, that's what it's all about. Everyone is entitled to an opinion but when it comes to the cruch we have to agree on somethings or we won't be able to communicate at all. I never said I was sticking slavishly to the PBP guidelines, and I would also like to hear other opinions on the matter.

            --
            -- "It's not magic, it's work..."
            • Yes it is. I didn't mean to sound "defensive" or anything. I was just curious for knowledge sake. I will not get to be going to OSCON so I guess I will have to wait it out.

              • I won't get to go to OSCON either. No offence taken, your point is the key to what I was saying, "using PBP/Perl::Critic" makes you think.

                --
                -- "It's not magic, it's work..."

    • You have a point, the book is just one set of guidelines. However I do think when you deviate you should ask yourself, am I doing this for a sensible reason, or is the PBP guideline actually a better way of doing things.

      I suppose the point is PBP makes you think, I'm not slavishly following the guidelines but so far it's forced me think and as part of the process I've found two no-ops and a subtle bug in one module.

      --
      -- "It's not magic, it's work..."

  • Is it really okay to deviate from PBP or [are] the guidelines really better?

    As I said in Chapter 1 of the book:

    As you consider these pieces of advice, think about each of them in the context of the type of coding you typically do. Question your current practice in the particular area being discussed, and compare it against the recommended approach. Evaluate the robustness, efficiency, and maintainability of your current coding habits and consider whether a change is justified.

    But remember that ea

    • So, yes, it's okay to deviate from PBP, as long as you think through that deviation, weigh it against whatever criteria you're using to define good programming practice, and stay on guard against the all-too-human tendency to rationalize bad habits.

      It's been a really useful process. I'm self taught and work mostly in a team of one (me), so an external viewpoint is really useful. As I said in my original post, looking at every deviation has forced me to think, and while in most cases I've gone with the PBP

      --
      -- "It's not magic, it's work..."
      • I am in exactly the same boat. I have no programmers around me so I picked up Perl to do some things myself. PBP gives me a guideline to go by and I am always interested in other ways or opinions.

        • There is nothing wrong with being self taught, but you do need to obtain an external view point now and then to make sure your going the right way.

          I've been on a Red Hat and an IBM AIX training courses. On both couses I realised I knew a lot already (the Red Hat more so), which is useful confirmation, and I also picked up a better understanding and for AIX in particular I did pick up some new stuff.

          Reading the PBP book and using Perl::Critic is a good way of getting an external perspective, but it's onl

          --
          -- "It's not magic, it's work..."
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.