Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Best practices, revisited

by CountZero (Bishop)
on Jul 05, 2009 at 19:04 UTC ( [id://777381]=note: print w/replies, xml ) Need Help??


in reply to Best practices, revisited

No battle plan survives contact with the enemy.(Helmuth Karl Bernhard Graf von Moltke)
Why would it be different with "Best Practices"? The value of Damian's book lies in the fact that he explains why he considers some practices "best". You may agree or not agree, but it is not presented as a fixed list never to be changed nor to be doubted.

If you find that a rule or a practice doesn't fit your style, why shouldn't you change it? But your argument to change it should be at least as good as the argument that imposes it.

For instance I'm a terrible typist (as all who read my CB-postings will readily agree), so I wouldn't think of writing even small scripts without "use strict;. On the other hand I rarely if ever "use warnings;"

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

Replies are listed 'Best First'.
Re^2: Best practices, revisited
by ysth (Canon) on Jul 05, 2009 at 19:25 UTC
    For instance I'm a terrible typist (as all who read my CB-postings will readily agree), so I wouldn't think of writing even small scripts without "use strict;. On the other hand I rarely if ever "use warnings;"
    I'd think you'd love the uninitialized warning, then. Maybe you never use constant hash keys?

      Or maybe not. Undef is too often a valid value or an expected return value. A warning for the read access to a nonexistent hash key might make sense. And would point to the line of the possible typo. Warning about the use of an undef, even if called "uninitialized value", is mostly pointless. It forces you to write more code and more code means more bugs and it often points to a wrong place in the code.

      If you are afraid of mistyping the hash key, lock the hash via Hash::Util.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

        undef silently becoming "" or 0 is definitely attractive, but to me far from worth going without warnings. I don't find the uninitialized warning at all pointless; it almost always indicates a bug (sometimes a typo, but sometimes a logic error.) The extra work to avoid the warning in correct code is trivial and hard for me to get wrong.
      For some strange reason I seem not to have a problem with hash-keys. They get rarely mistyped.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://777381]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2024-05-23 13:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found