Talk:Coding Guidelines
Language standard: American English
In IRC someone told me that the Koha language standard is American English (en_US), but I see everywhere words in others English alternatives, and no bug report intend to fix this, nor (AFAIK) a explicit guideline to stop doing this.
- Do you have some examples maybe? I think we agreed to en_US a while ago, as the majority of words seemed to be American English back then. For translations it's also always good if there is only one spelling of a word. --Kfischer 03:33, 18 December 2014 (EST)
- Off hand: in American English, authorised_values would be spelled authorized_values. --Barton 10:07, 26 April 2017 (EDT)
Should we link to the System_Preferences page?
https://wiki.koha-community.org/wiki/System_Preferences
Victor Grousset - tuxayo 12:21, 7 February 2018 (EST)
Add guideline for variable names
http://irc.koha-community.org/koha/2018-02-07#i_2008271
> camelCase, complete words, readable, meaningful
--Victor Grousset - tuxayo 12:38, 7 February 2018 (EST)
Command-line argument conventions
We should decide on a convention for command-line argument processing and stick to it:
The problem is... Some people may have already created scripts (for crontab jobs, like you said) already relying on "rebuild_nozebra.pl" running right away. For "--help" I think we should add "usage" instructions (I don't think that breaks any thing).
Yeah, adding "--help" to jobs that don't have it shouldn't break crontabs.
As proposal of convention rules, the GNU coding standards, http://www.gnu.org/prep/standards/ . In particular the option table and two standard options http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces
Documentation
I would like to propose the introduction of a second documentation rule to encourage the submission of documentation entries for any new features
DOC2
All submissions of 'New Features' should have a corresponding submission to document the new functionality.
The documentation team is unanimously in favor of this new guideline :) We sometimes find it hard to know exactly what a new feature does, and we feel the developers are the ones who know the feature the best
Proposal to remove the PERL20 and PERL20.1 guidelines after merging them with PERL15
TL;DR: In the interest of decluttering the list of Perl guidelines, I am suggesting we action an earlier proposal to merge PERL20 and PERL20.1 with PERL15.
While editing the Coding Guidelines page earlier today, I noticed Perl guidelines PERL15, PERL20 and PERL20.1.
In the Development IRC meeting that took place on March 1st 2016, there was an item in the agenda (added by Katrin) involing these guidelines: "Merge new PERL20 and PERL20.1 into PERL15".
According to the minutes of that meeting, there was a related action item for which Kyle volunteered: "khall to propose a wording for the Moo,not Moose and PERL20, PERL20.1 and PERL15 fusion ;)".
I had a look at the revision history but could not find any edits of the PERL15 guideline after March 1st 2016 related to the above action item.
PERL20 consists of a single recommendation: "Modules in the Koha namespace sould be object oriented when possible, using Koha::Object(s) as a preferred base."
PERL20.1 consists of a single recommendation, too: "If a Koha::Object already exists, use it instead of other methods of table CRUD."
There are no Wiki pages that link to PERL20 or PERL21, or any other references to these two guidelines.
On the other hand, there is a PERL15 section in the Developer's handbook (which I appreciate is a work in progress).
Also, there is a revision comment by Jonathan which claims that "PERL15 is a defacto rule".
With all that in mind, provided PERL20 and PERL20.1 are still valid from Koha's OOP standpoint I'd like to go ahead and merge them with PERL15.
Please see below for my suggested "patch" đ:
--- before 2023-08-04 14:23:02.120593382 +0200
+++ after 2023-08-04 14:25:19.632064357 +0200
@@ -1,3 +1,11 @@
==== PERL15: Object-oriented code and the Koha:: namespace ====
-Whenever it makes sense, code added to the Koha:: namespace should be object-oriented. However, code that is naturally procedural should not be shoehorned into the OO style. Modules in the Koha:: namespace should not reference the C4:: namespace, with the exception of <tt>C4::Context</tt>.
+Whenever it makes sense, code added to the Koha:: namespace should be object-oriented.
+
+However, code that is naturally procedural should not be shoehorned into the OO style.
+
+Modules in the Koha namespace sould be object oriented when possible, using Koha::Object(s) as a preferred base.
+
+Modules in the Koha:: namespace should not reference the C4:: namespace, with the exception of <tt>C4::Context</tt>.
+
+If a Koha::Object already exists, use it instead of other methods of table CRUD.
--Andreas Roussos (talk) 12:39, 4 August 2023 (UTC)