matt hellige wrote: > there seems to be an awfully strong bias against using hard tabs with > a configurable displayed width. i'd like to describe a situation where > i believe that option makes a lot of sense... suppose you're working > on a team of programmers on a project, and you need to come up with > some coding standards, since you all agree that's a wise thing to do. > no suppose 40% of the programmers like a 4-space indent, 40% like a > 2-space indent, and the other 20% like an 8-space indent. what to do?
You decide upon a single style by whichever system you consider appropriate (company policy, team vote, team leader's discretion, etc), then require everyone else to follow it. If someone refuses to accept common coding standards on an issue as simple as formatting, the team is likely to be better off without them. This doesn't just apply to commercial development, either; even OSS projects will reject code which doesn't meet their formatting criteria. > well, if you're all using relatively smart editors, the traditional > solution is to mandate the use of hard tabs, and allow people to > configure their editors however they want. that way i can see: [snip] > cvs always sees the same thing, and we're all happy. obviously, this > only works if indentation is used ONLY to indicate nesting depth and > NEVER to align text vertically at some specific column. That's a pretty big if. It's quite common to use tabs for aligning code or data which has a tabular form, i.e. multiple consecutive lines with a common overall structure (e.g. repeated calls to the same function with different actual arguments, array/list initialisers, etc). > in fact, this brings to mind a question about the layout system. > currently, is a tab character ALWAYS interpreted as eight spaces, or > is it treated as "go to the next tab stop", where tab stops are every > eight spaces? if it's the latter, i live in fear! Tab stops are every 8 columns, and a tab character moves to the next tab stop. So a tab corresponds to between one and eight spaces, depending upon the column in which it occurs. This is the same interpretation as everything else uses (except where explicitly reconfigured to behave otherwise). I've never encountered anything that treated a tab as 8 spaces regardless of column, or which defaults to any value other than 8. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe