[Koha-devel] Coding guidelines

[Renvoize, Martin]

Ooops, I forgot to reply to this.

It looks good to me Marcel.


*Martin Renvoize*

<https://www.ptfs-europe.com>

Development Team Manager

Community Release Manager (19.11, 20.05)


*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvoize at ptfs-europe.com

*Fax:* +44 (0) 800 756 6384


www.ptfs-europe.com







Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com




On Wed, 29 Jan 2020 at 16:25, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>
wrote:

> 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/20200211/507e7111/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/20200211/507e7111/attachment.png>