Hi, On Fri, Feb 12, 2010 at 10:51 AM, Colin Campbell <colin.campb...@ptfs-europe.com> wrote: > Also a quick unscientific scan through the existing codebase a few days > back revealed 96.96% of existing lines are 80 characters or less ( 99.7% > are less than 100) so that perltidying with a long line length may have > a detrimental effect in some cases. Also it seems we are by default > using shorter lines.
I think 132 is a good compromise value - 80 is too short, IMO. > I think we should resolve this before considering any cleanup operations. Cleanup should be done with some care, however. First, although it's not common at all for perltidy to break code, it can happen - whitespace-only patches need to be tested the same as any other. More importantly, it is essential that whitespace changes be separated from bugfixes and functionality patches. In other words, please don't make a change, then run perltidy on the files you touched, then commit - the resulting patch will likely have a lot of diff lines that are extraneous to the bugfix itself. Instead, please make your change, then commit, then commit the perltidy change (or vice versa). I'm in favor of adopting consistent formatting of the code. I would even go so far to suggest that we move towards requiring frequent contributors to run new work through perltidy before submitting it. However, if there's any inclination to do a mass reformatting of existing code, I think there's only one not-bad time in the near future to do it - at the very beginning of 3.4. Unfortunately, there's never going to be a painless time to do a global cleanup: doing it now will make it more difficult to process patches and stray kittens for 3.2, while doing it at the beginning of 3.4 will make it more difficult to backport bugfixes into the 3.2 maintenance branch. Regards, Galen -- Galen Charlton gmcha...@gmail.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
