Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^2: Avoiding silly programming mistakes

by JavaFan (Canon)
on Aug 20, 2008 at 09:43 UTC ( #705459=note: print w/replies, xml ) Need Help??

in reply to Re: Avoiding silly programming mistakes
in thread Avoiding silly programming mistakes

Yada, yada, yada. You're parrotting the Perlmonks dogmata (strict, warnings, tests, etc), but none of this would have actually helped the case the OP describes. Neither strict nor warnings tell you a DESTROY function is placed in the wrong class. And while tests can tell you something is wrong, figuring out that something was wrong wasn't the OPs problem.

Not writing code is a good point though. A necessary requirement for bugs is code. Without code, there cannot be bugs (at least, not the bugs we're discussing). However, using other peoples modules means you got to write code. Furthermore, the fact code exists on CPAN doesn't mean there are no bugs. All it says is that the author of the code has figured out how PAUSE works.

  • Comment on Re^2: Avoiding silly programming mistakes

Replies are listed 'Best First'.
Re^3: Avoiding silly programming mistakes
by GrandFather (Sage) on Aug 20, 2008 at 12:24 UTC

    It's a fair bet that the OP won't repeat the DESTROY mistake again for a while and it's a much better bet that strictures will pick up silly errors way before the repeat of the DESTROY error.

    The dogma are dogma because they are valid and relevant to many of the problems people bring to PerlMonks. There is a chance that a first poster here hasn't met them before and even if the OP uses strictures, it is another safe bet that someone reading this thread in the future doesn't use strictures and will benefit from them.

    Strictures aside (it seems you may not have not have noticed the smiley), I offered advice on a number of levels to address a range of issues. There are no panaceas that resolve all such issues and nothing can prevent typing the wrong character in the first place, but tools that catch common errors early help a lot.

    CPAN is a huge resource. It contains a fair amount of dross for sure. But it also contains a huge amount of well written, well documented and tested code that is widely used. That's a heck of a lot of code that you don't have to write. Yup, there are probably bugs in every CPAN module, but if you can write equivalent code that is bug free despite 'still making "doh" mistakes' then get out and publish!

    Perl reduces RSI - it saves typing
Re^3: Avoiding silly programming mistakes
by TGI (Parson) on Aug 20, 2008 at 15:19 UTC

    The various "best practices" dogmata you seem to decry have evolved in the Perl community because Perl gives the programmer a lot of freedom--to screw up or to do magic for good or evil.

    Other languages focus on technical restraints to prevent bad programming. Perl relies on cultural norms.

    Whether this is a feature or a bug is open for discussion.

    For some reason, you seem to be against the use of strictures and warnings (but, maybe I am misreading your posts and you only oppose blind dogma). These pragmata do an excellent job of catching d'oh type errors. Misspelled a variable? Used it out of scope? Typed if( $foo = 3 ). Warnings and strictures just saved you time, potentially hours. So, to my mind, they are particularly appropriate to mention in this thread.

    If you don't see a use for strictures and warnings, try hacking some PHP for a while. If you type as badly as I do, anything over a few hundred lines will start to hurt.

    Update: I'm happy to be wrong. The use of strictures is important, and I am very glad to see that you agree--especially glad to see that you say "almost all" your code.

    The core disagreement here is whether it is appropriate to apply this advice in this thread. I think it is, you think otherwise. No big deal.

    You are absolutely right to mention the other 254 practices in PBP. (Although not all of them should be followed--which is a topic that has been thoroughly debated.) PBP was my first thought on reading the OP--but someone else had already posted a pointer to it.

    TGI says moo

      You are misreading my posts. Compeletely. I'm not against using strict or warnings - I use it in almost all my Perl code.

      I am against the many posts suggesting to use 'strict' or 'warnings' when such things have little to do with a problem someone posts. At least, if you cannot contribute much to the problem except reciting mantra, come up something original. There are 254 other best practices mentioned in Damians book. ;-)

        Considering the number of code problems strictures and warnings can help alleviate or eliminate, some won't answer questions or offer help regarding code which is written without them. Is that a good enough reason to convince people to use them?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://705459]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (2)
As of 2017-01-17 04:08 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (151 votes). Check out past polls.