[Marcin 'Qrczak' Kowalczyk ]

All these problems are caused by people who use a different tab size than 8. With consistent tab size there is no reason to convert between tabs and spaces.

i've tried to avoid getting involved in this, but now i can no longer resist. fist and probably most importantly, it becomes clear that the layout arguments revolve around personal preferences, and what we can call "meta-preferences," statements like: "for these good reasons, i'd prefer that no one have that particular preference." unfortunately, someone will always think differently, and what is intuitive to one person will invariably make no sense to someone else. so the danger here is that a community of like-minded individuals will end up making decisions and anyone who has un-fashionable preferencees will feel excluded and frustrated, and may throw the baby out with the bathwater. now, programming languages are, by nature, nothing BUT a lot of preferences, so it's a pretty fine line, but in many cases it's important to support those members of the community whose preferences you do not share, and indeed whose preferences you consider unreasonable. the fact is, ingo's points are reasonable. for large multi-developer projects, it's very important that there be some way of automatically finding semantic changes in source files. anyone who has ever needed to figure out what another programmer "actually" changed in a source file that they also completely re-indented before checkin knows how painful this can be. "diff -b" can be a godsend, but obviously, only if whitespace is insignificant. 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? 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: for () { // do some stuff... if () // do something else... } and the guy in the next office can see: for () { // do some stuff... if () // do something else... } 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. it seems that many people on this list prefer laying out haskell code with vertical alignment, in which case these coding standards would not make sense, but there has been some support for a strict nesting depth layout style as well. all in all, i think it's neat that haskell supports different layout styles, and i think it was VERY wise to support a non-layout syntax as well (compare with python, which many people refuse to touch because they enforce layout, and people consider it unmaintainable). my only concern about the whole system is the interpretation of tab characters. as irritating is it is when make complains that you're using spaces instead of tabs (is there a programmer alive who was never mystified by "*** Missing separator. Stop."?), at least there can be no disagreement about how many spaces equal one tab. i would PREFER if haskell enforeced a strict distinction between spaces and tabs for layout purposes, i.e., this: let x = y ^I z = q ^Iw = l in ... should be an error. if a given indent is noted as "^I ", subsequent lines must match exactly. no number of spaces will every "equal" a tab. 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! not sure if i should send this or just cancel it... ;) matt -- matt hellige matt@immute.net http://matt.immute.net

[Glynn Clements ]

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.

sure. i agree that coding standards are important. if they weren't, clearly it would be a non-issue... my supposition here is that you want to find a style that pleases as many programmers as possible. i see no reason to be intentionally frustrating... ;)

...

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).

sure. in many cases it won't work, which is why, at my last job, we settled on four spaces per indent, and eschewed tabs entirely. which still doesn't mean that that's the One True indentation style! m -- matt hellige matt@immute.net http://matt.immute.net

...

...

...

...

"m" == matt hellige writes:

m> sure. i agree that coding standards are important. if they weren't, m> clearly it would be a non-issue... my supposition here is that you m> want to find a style that pleases as many programmers as possible. i m> see no reason to be intentionally frustrating... ;) Now I really, really hate Haskell's layout syntax. But for sure, tab size isn't an issue here. You seem to regard it as a style issue when in fact it has nothing do with style: it's a *representation* issue for your source code. If you can't "agree" on tab size, you might as well not agree not to use EBCDIC. Any text editor worth its money let's you configure what the tab key does completely independently from how it displays ASCII TAB characters in the text, so differences in tab size aren't even visible to the user; you might as well configure the de-facto standard. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla