Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: On Commenting Out 'use strict;'

by dragonchild (Archbishop)
on Aug 11, 2005 at 14:24 UTC ( #482973=note: print w/ replies, xml ) Need Help??


in reply to On Commenting Out 'use strict;'

This isn't just a Perl issue or even a programming issue. Database work also generates warnings and errors that most developers just ignore. I've gone ahead and fixed warnings on SQL scripts for different databases and ended up fixing both long-standing bugs and bugs they didn't even know they had.

Lesson: Warnings are there for a reason. You shouldn't ignore a warning unless you have researched it and determined that you actually want to do whatever it is that's triggering the warning. THEN, you go ahead and document that this warning is expected and the reason why it's ok. AND THEN, you have another developer sign off on it. Both your names are in that comment forever and ever, amen!

Personally, in over 10 years, I've never run into a situation where a warning was actually warranted. But that's just me.


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?


Comment on Re: On Commenting Out 'use strict;'
Re^2: On Commenting Out 'use strict;'
by Anonymous Monk on Aug 11, 2005 at 15:57 UTC
    Lesson: Warnings are there for a reason.
    Yeah. Too bad some warnings are there because someone thought "I think this is bad coding style, let's issue a warning", and had their patch accepted. Luckely, most proposals like that never make it, but some did.
    You shouldn't ignore a warning unless you have researched it and determined that you actually want to do whatever it is that's triggering the warning.
    Yeah, but in most cases, it's bloody obvious.
    THEN, you go ahead and document that this warning is expected and the reason why it's ok.
    # Perl thought I thought that perl thought differently. # Once again, perl was wrong. # // Anonymous Monk, today. no warnings 'some category';
    AND THEN, you have another developer sign off on it.
    Right. And next time, have him sign off when I want to blow my nose as well.
    Both your names are in that comment forever and ever, amen!
    Don't think so.

    But you left out the important thing. You don't let the warning be issued, you turn it off using no warnings.

      I think we have a fundamental difference in assumption about what code is and what it is not. My assumption is that the code I write is not mine in the way that my underwear is mine. I write code that part of a group's work. The stuff I type in will be edited by someone else and I will be editing code that someone else typed in.

      With that in mind, I have to try to write my code as strictly as possible. This means turning on all strictures and warnings. Now, I have, do, and will write code with soft references in it, in violation of strict-refs. I have, do, and will write code that needs no warnings 'uninitialized'.

      I suspect the difference between you and I is that I am directly accountable to other people. These people are extremely programmers, but I'm still accountable to them. So, I have to demonstrate why I feel that strict-refs or no-warnings is appropriate.

      The thing I always return to is that the warning is describing a potential error condition. By turning off warnings, I'm turning off a error-detector. Sometimes, it is annoying, but it's saved my butt at 3am on Saturday more often than I'd care to admit.


      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^2: On Commenting Out 'use strict;'
by TomDLux (Vicar) on Aug 11, 2005 at 20:48 UTC

    When I was assigned to correct some error in one day's processing, I examined every detail item by item, since I wasn't familiar with the system. While the people familiar wth the system could leap from point to point, quickly narrowing in on the error, I had to be as picky as an accountant, verifying everything was correct. As a consequence, I discovered several errors that had been there for years, that no one was aware of.

    Moral of the story: the big picture is good, but details are important, especially when they're wrong.

    --
    TTTATCGGTCGTTATATAGATGTTTGCA

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2014-09-16 09:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (158 votes), past polls