Line endings

David Terei davidterei at gmail.com
Fri May 13 05:34:07 CEST 2011


I personally would be very happy paying the cost to get rid of tabs in
a big swoop. Maybe we could try to plan for a time right after 7.2
when there may be a little less code in peoples branches and just go
for it. Or perhaps we could stagger it? Say each week we choose a
folder in the ghc source tree and for that week its designated cleanup
time for the folder. We could also use this to fix up various other
cleanliness issues with GHC's code. There are some pretty old todos
and notes and people asking questions from 4 years ago in the
comments. Would be nice to clean that all up as well as these things
defiantly made it more difficult for me when starting out with GHC.

Staggering would also work well in that it would give people a chance
to object to an area undergoing cleaning that week if they have a lot
of out of tree changes. This would pollute the history for a while but
I think its worth paying that cost.

Then once done we can have git reject pushes that contain tabs and
other bad things.

I don't think we should overlook the value of having well formatted,
clean code. It helps lower the barrier and encourage new contributors
to get involved. For a more radical example of a open source project
that takes clean code seriously check out Postgres:

http://momjian.us/main/blogs/pgblog/2011.html#April_20_2011

On 12 May 2011 06:52, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Thu, May 12, 2011 at 2:12 PM, Max Bolingbroke
> <batterseapower at hotmail.com> wrote:
>> If we outlawed them now we'd have to take an annoying one-time hit
>> removing all the (tons) of existing tabs, generating lots of merge
>> conflicts on all GHC branches for little immediate gain :-(
>>
>> So while I share your sentiment, I don't think eliminating tabs would
>> be worth it in cost/benefit terms.
>
> Perhaps we could just avoid adding new ones? I think you can make git
> check for new whitespace violations in a pre-commit hook. The problem
> I have with mixed spaces/tabs is when I cut-n-paste code (come on,
> we've all done that) you can have strange compilation errors due to
> copying code that was indented using tabs into code that was indented
> using spaces.
>
> Johan
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>



More information about the Cvs-ghc mailing list