Do you write the following?

my %hash= ( key1 => scalar lc $value );

If not, then it is probably because you know that 'lc' just returns a scalar. If you do, then there are probably a lot of people who find you silly. 'lc' isn't the only function I use that just returns scalars. Sprinkling 'scalar' all over hellenbach doesn't improve code much in my experience.

I actually consider the => to be broken for not enforcing scalar context on both sides. But that still just shifts the problem to things like function arguments.

Why haven't you written a 'string' function that forces all arguments to be treated as strings and asserts if given a reference? And an 'integer' and 'float' function that asserts when given things not appropriate for those context? Then you can fix all of your broken assumption-filled code:

if( boolean( integer($scale) < integer(scalar getMaxScale()) + ) || boolean( scalar isExempt() ) ) { Report( string( scalar getName() ), float( (integer($base)+integer($bonus)) / integer($count) +), ); }

Yes, that code looks much easier to maintain. [Oops, I left off one boolean().]

And what about all of those places where my list context is implicit? Surely those need to be made explicit too? I'll write partOfList() that asserts if not called in a list context.

if( boolean( integer($scale) < integer(scalar getMaxScale()) + ) || boolean( scalar isExempt() ) ) { Report( partOfList( string( scalar getName() ) ), partOfList( float( (integer($base)+integer($bonus)) / integer($cou +nt) ) ), ); }

Now, there are places where using scalar() is more appropriate. But, no, I don't consider using it on a function that just returns a scalar to be such a place. And I don't think transforming every function that might want to return an undefined scalar into "a function that returns a scalar except when it wants to return a undefined scalar in which case it returns an empty list instead and if you really wanted the undefined scalar then you should wrap the call in scalar() for that purpose" to be even close to an improvement strategy.

- tye        


In reply to Re^4: Module Announcement: Perl-Critic-1.01 (scalar) by tye
in thread Module Announcement: Perl-Critic-1.01 by jthalhammer

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.