[Bioperl-l] Perltidy and... SVN and ...Re: Perltidy

[Sean Davis]

Chris Fields wrote:
> 
> On Jun 15, 2007, at 5:56 AM, Sean Davis wrote:
> 
>> Sendu Bala wrote:
>>> If its going to be difficult and a hassle, for such an unnecessary thing
>>> I'm not sure its worth it. There are more pressing things to be done for
>>> Bioperl.
>>>
>>> If I can just run perltidy on the entire package and commit, I'd do it.
>>> If that's not appropriate, I won't.
>>
>> I agree with the sentiment noted above.  I'm a bit of an outsider here,
>> but bioperl is a collaborative project.  Not everyone has the same
>> sentiments about what "correct" style means.  As a programmer, I really
>> wouldn't want significant changes on the style of my code.  And perl
>> happily puts up with many styles.  I would say leave things as they
>> are--let the individual programmers choose.  It reduces the amount of
>> work of questionable importance and allows the coding style freedom that
>> perl supports.
>>
>> Just my $.02.
>>
>> Sean
> 
> I tend to run it on modules that need some reformatting (SearchIO::blast
> comes to mind).  I believe you're correct when this comes down to
> programming style, but I think this echoes a sentiment (frustration,
> perhaps) that some of us have with long-term maintenance of said code.
> 
> Maybe a compromise:  include a copy of .perltidyrc with the distribution
> that goes by what a consensus wants or by the general rules laid out in
> Perl Best Practices (spaced settings, use of spaces over tabs, etc). 
> Conversion would be encouraged but voluntary, with the caveat that if
> someone needs to clean up code down the road (bug fixes, enhancements,
> etc) and if the original author isn't able to add it in themselves, it
> could be perltidy'd in order to help the developer (locate and fix the
> issue)|(add relevant enhancement where needed).

Don't get me wrong--I think whatever makes bioperl a better, more
maintainable beast should be what is done.  The bioperl gurus should
absolutely do what is best for them for code maintainability.

Sean