[Koha-devel] BibLibre strategy for Koha 3.4 and next versions

[Colin Campbell]

As everyone has pointed out 400+ is a lot and liable to generate a bout
of indigestion, but as Paul pointed out in his original email we need to
up our game when it comes to managing the product of all that work.
Small improvements could make life easier for all. If the patch
introduces a feature or changes how one behaves is it documented? The
pod should answer the puzzled why of anyone reading the code.
Are there tests? (And if so does it pass them)
We really need to take testing much more seriously, coverage of the code
is minimal, (and we still don't have a code base that runs cleanly with
use warnings!!).

There are some trivial things you could do, before submitting the patch
make sure that you're not adding any meaningless whitespace at the end
of lines ( git diff shows it) it helps keep future diffs, merges etc
less labour-intensive. Does your code show its intention clearly.
Trivial points like variable names (data and results don't convey much
more than using random strings of hex digits), don't be obscure
(changing e.g. hldct to hold_count removes ambiguity especially to a
fellow programmer who may not be a native speaker of your dialect of
English). Does the code need breaking up into subroutines? (Programmers
have very short attention spans - about a screen and a bit and even
shorter in if else blocks).

Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 208 366 1295 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com