Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .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