[Koha-devel] Coding guidelines

Jonathan Druart jonathan.druart at bugs.koha-community.org
Mon Feb 17 11:57:19 CET 2020


Hi Marcel,

Sorry for the late reply.
All looks ok to me as well, only a couple of things:

15b: better to point to C4 than c/p code from there to Koha :) Ideally the
code should be moved to Koha, then used from there. But no always a
solution I guess.

15c: On 22407 comment 3 I listed the different cases of the relationship,
and how we should use them.
ie. no "return unless" if not necessary, etc. I think they could be copied
to the wiki as an example to follow
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407#c3

And a question about 15a, what could be a good reason to not use OOP in
Koha?

Thanks!
Jonathan


Le mer. 29 janv. 2020 à 17:24, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl> a
écrit :

> Referring to the dev meeting and bug 22407, I propose the following
> rewording:
>
> PERL15 Using Koha::Object[s]
> PERL15(a) Code added to the Koha:: namespace should be object-oriented
> unless there is a very good reason to do otherwise. In that case the reason
> should be documented clearly.
> PERL15(b) Code in Koha::Object[s] should normally not refer back to C4.
> Obviously, this cannot be enforced harshly until the refactoring has been
> completed.
> PERL15(c) Use DBIC relations to (pre)fetch a related Koha object rather
> than searching it explicitly. (See bug 22407)
>
>
> PERL28 Other object oriented code guidelines (in addition to PERL15)
> I think we need to move the Accessor and idiom for -> new rules from
> PERL15 to another rule. I opened rule 28 for that depending on discussing
> the following:
> Class::Accessor is a great way to provide access to member variables.
> => My suggestion would be to remove this rule. It is true but we do not
> say that it is the only way to do it. (We are not even using
> Class::Accessor in Koha objects.)
> Or just say PERL28(a) To provide access to member variables, there are
> several ways including but not limited to using Class::Accessor.
>
> A useful idiom for the ->new() routine in object-oriented classes that do
> not need to process the arguments passed in as a hashref but merely need to
> save them for future processing
> => This suggestion is fine. It says use a parameter hash for sub new. We
> normally do that. Reworded:
> PERL 28(b) Use a hashref as second parameter in sub new when passing
> arguments.
>
> Any feedback?
>
> Marcel
>> [image: http://www.rijksmuseum.nl] <http://www.rijksmuseum.nl/>
>
> ​Museumstraat 1
> Postbus 74888
> 1070 DN Amsterdam
> *Rijksmuseum.nl* <http://www.rijksmuseum.nl/>
>> ​Nu te zien:
> *Operatie Nachtwacht​* <https://www.rijksmuseum.nl/nl/nachtwacht>
>> ​Verwacht:
> ​*Caravaggio-Bernini. Barok in Rome*
> <https://www.rijksmuseum.nl/nl/caravaggio-bernini>
> *​Dankzij Waller 2010-2020*
> <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht/dankzij-waller-2010-2020>
>
>> ​T/m 18 jaar gratis
>
> Please think before you print
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200217/82199982/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image826795.png
Type: image/png
Size: 2974 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200217/82199982/attachment.png>


More information about the Koha-devel mailing list