[Koha-devel] perltidy

[Galen Charlton]

Hi,

On Fri, Feb 12, 2010 at 10:51 AM, Colin Campbell
<colin.campbell at 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
gmcharlt at gmail.com