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

Reply via email to