[Koha-devel] Add rule for no subroutines in PL scripts

[David Cook]

Thanks for that Tomas. I don’t think I have anything substantive to add. 

 

Recently, I’ve done a lot of work on another Perl project which often doesn’t use subroutines or has them scattered around in files, which make them impossible to test. It makes development more difficult and it makes releases a nightmare. As Tomas says, you need to be able to test everything. If you think about it in that way, no code is every used once. It always has to be used at least twice. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St, Ultimo, NSW 2007

 

From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] 
Sent: Thursday, 1 October 2015 12:19 AM
To: Philippe Blouin <philippe.blouin at inlibro.com>
Cc: David Cook <dcook at prosentient.com.au>; koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Add rule for no subroutines in PL scripts

 

 

2015-09-30 9:20 GMT-03:00 Philippe Blouin <philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com> >:

Because the code would be extremely specific to a specific functionality, whereas the code in the libraries is there to be reused.
And let not go overboard with OO.

 

We embrace the OO paradigm for most of the CRUD operations, but we also have libs containing functions that are used statically, like Koha::Util::MARC, that do specific things and are testable. And is only used in a couple places.

 

A script is a script is a script.  Make it readable, add functions to make it cleaner, make your functions readable.

 

We have two main kind of scripts: command line scripts, and controller scripts that got too complicated during Koha's life, and we are trying to simplify "as we go".

 

I think both should be testable.

 

And make some rule for forbidding direct DB accesses, so that future DB changes do not require to change many scripts.
But please, do not forbid functions in scripts.

As for tests, writing them for very complicated, very very specific function only applicable to a script could have value, but it certainly does not balance the extra complexity your bringing to the code.

 

I'm trying to think of a use case for that, and I'm not sure we really have that kind of situations. We might consider on a per-scenario basis BUT, the whole point is that no super-complex code should lack full coverage tests. Because the more complex the function, the more difficult for people to know they are not breaking a feature if they touch it.

 

So, even if we didn't write this rule down, the most probable scenario is that the release team would fail a patch adding complex functions that don't provide unit tests.

 

This is not a religious/fanatic thing, but a practical one. Trying to pay our technical debt and interests instead of adding more debt.

 

 

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20151001/4b3229b4/attachment-0001.html>