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) [email protected] skype: colin_campbell2 http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
