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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|