in reply to Re: Is there a better way to do this?
in thread Is there a better way to do this?

Thanks!

I understand and agree with both your points. I know I write my code quiet loose, usually because I know that the people I code for come up with the most annoying exceptions several months down the line :-)

I was most worried about sam::add_status so I'm glad that has passed inspection so far. I just need to improve everything else.

Thanks again for everyone who has replied.
  • Comment on Re^2: Is there a better way to do this?

Replies are listed 'Best First'.
Re^3: Is there a better way to do this?
by afoken (Chancellor) on Dec 15, 2010 at 17:30 UTC

    If you are interested in how good your code "looks", install Perl::Critic and run the perlcritic utility. Note that perlcritic knows many rules, and there are several rules that can be ignored or broken. After all, it is a tool to compare perl source with the recommendations in PBP. Perl itself doesn't really care how your code "looks", but your future self perhaps will, because he has to maintain what you write now.

    In default mode, perlcritic finds only one thing:

    # perlcritic .
./877252.pl source OK
./sam.pm source OK
./status.pm: "return" statement with explicit "undef" at line 45, colu
+mn 3.  See page 199 of PBP.  (Severity: 5)
./tes.pm source OK

    [download]

    In "brutal" mode (perlcritic --brutal .), perlcritic spits out 96 lines, each with a major or minor problem. Missing version control system markers, indirect object syntax, useless interpolation, whitespace at end of line, and of course the all-lowercase module names, to name some.

    All-lowercase module names are reserved for pragmatic modules, you should perhaps change your module names to start with an uppercase letter. Also, when your project grows, better have a separate "namespace" for it. If you have no better idea, start with your name or your company's name, followed by the project name. E.g. BigCorp::Frobnicator::Parser, BigCorp::Frobnicator::Generator, BigCorp::Frobnicator::Logger.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      Thanks again. looks like I will be using perlcritic a lot from now on. I'm always very concious that someone will eventually have to take over my code (I hope!)

      As for the module names, I confess that was just laziness on my part just for this experiment/post. I didn't want them to get mixed up with Sample and Test which are the existing modules so I changed the case - and then stripped off the ends of the names too for the hell of it.

      I'm surprised it doesn't complain about the lack of commenting too.

      Thanks again
[reply]
        looks like I will be using perlcritic a lot from now on.

        Take it serious, but not too serios. PBP is just that. Best practices, not religion. You will probably not burn in hell if you ignore it. But the one that has to take over your code may wish so. ;-)

        In fact, not all "best practices" in PBP are considered "best" among the perlmonks. For that reason, you can configure perlcritic to ignore some rules, or to rate them higher or lower than default.

        I'm surprised it doesn't complain about the lack of commenting too.

        Comments != documentation. See Pod::Coverage and Test::Pod::Coverage.

        I prefer having only few comments in my code, mostly only in places where I fear that my future self may come back and hurt me, i.e. whenever I choose to write cryptic code, use side-effects, or assume special conditions.

        Documentation is a completely different thing. At least the API should be clearly documented, often also the algorithms used.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

In Section Seekers of Perl Wisdom