Re: Perl::Critic Tests

["R. Ransbottom" <..hidden..>]

On Wed, Apr 26, 2017 at 07:47:15AM +0200, Erik Huelsmann wrote:
> On Tue, Apr 25, 2017 at 5:12 AM, R. Ransbottom <..hidden..> wrote:

> ...
> The point here was that for clarity of code, it's best to have a function
> either return an array/list or a scalar. While returning "one or the other
> based on context" results in some elegant code, I'm with Matt that it does
> not solve the problem of casting values from scalars to arrays and back in
> a program of moderate size. But if it doesn't, then maybe it's better to
> have clear intentions all the way.

This states the basic misunderstanding that I am trying to address.  Yes, a
function returns a list or scalar.  Whether the caller gets a list or a scalar
depends on the context.  You think you are avoiding that but you are not.
Your explicit return undef will give a scalar undef or a list with one undefined
element.  You think that is better than an empty list or a scalar undef because
it happens to work for you in one situation.  

> > The bare return is a basic building block of some standard and

> My interpretation of it all is that Matt claims (and I fully understand his
> position) that these simpler idioms are a  source for bugs because the
> resulting program may not do  what the unsuspecting programmer thinks it
> does, especially in the context of returning empty lists.

I say that enshrining 'return undef' is trying to create a too
simplistic idiom.  That the functions become very special purpose for
no good reason.  Context is inescapable.  That the idiom is fundamentally 
flawed. 

My reply to your other message will expand on this.

> > If we promote bad standards of coding we will discourage the better coders ...

> True, but elegant code which has a high(er) risk of being insecure can't be
> construed as "better code", can it? 

You are agreeing and disagreeing and saying better coders will make worse code
and better code is elegant so more likely bad.  Not much code is elegant, so 
don't worry about that.

> the project would be those who put secure coding over everything else. In
> ...
> The second characteristic we'd look for in people who want to join is that

I would gladly read the continuation of the this priority list intertwined with
programmers' characteristics.

> did run to get the warning, meaning that the damage has already been done.
> Warnings don't prevent code from being unsecure. They might help to detect
> cases after the fact thought.

That is said as if all the bugs are caught before release.  

Every warning should be investigated and resolved in development.  That is 
the principle behind our using perlcritic to get more warnings.

Lexical warnings can be escalated if that is what we want.  That can create
more robust code.

> As for "burried at the bottom", I'm thinking that it should be clearly
> stated in the API documentation: the place to look for any user of an API
> function.  So, I hope that given enough time there won't be a need to read
> all of our code in the code base in order to be able to extend LedgerSMB.

This is sufficient where warnings are not?

I agree, it should be in the docs.  I think the docs should be shipped with
the code, so they will have a greater chance of being read and understood.

Be well,
Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel