Tabs/spaces coding style question

Paulo Cesar Pereira de Andrade pcpa at mandriva.com.br
Wed Nov 19 12:11:56 PST 2008


Jeremy Huddleston wrote:

> FTR, the replacement of 8 spaces with a tab in indentation is one of
> my biggest pet-peeves in poor coding etiquette.  Either use a tab
> consistently to denote one level of indentation and have people setup
> their editor to "display" tabs differently, or force spaces and /bop
> people over the head when they have a tab in leading whitespace.

  This probably was generated by the fact that there was a "CodingStyle"
document that said that X server and libraries should use 4 spaces
indentation.

  One sensible solution would be to only use spaces, but people
also likes the idea of using tabs for "compressing" files.

> This "mix" that some of the code currently employs just makes my
> editor wonkey because it treats the tabs as 4-spaces because of my
> 4-space-indentation setting (yes, I could probably change my editor
> settings, but I don't want to, and I shouldn't have to)...

  AFAIK all unix (not counting recent qt/gtk text widgets) editors
use 8 spaces tabs, while windows and mac ones use 4 (or 2) spaces.

  I think there was a quote from Linus Torvalds, where he says
that a tab is 8 spaces, and changing it is like trying to change
the value of pi...

> On Nov 19, 2008, at 10:46, Adam Jackson wrote:
>
>> On Wed, 2008-11-19 at 09:57 -0800, Dan Nicholson wrote:
>>> Sorry for the bikeshed question, but I'm confused by what style I
>>>  should be using when patching the server. It seems that the
>>> consensus is 4-space indentation, and that's fine. But I keep
>>> seeing that when the opening indentation is at least 8, real tabs
>>> are used to fill as much as possible. Is that the intention? If
>>> not, should I keep that style when patching into code that does?
>>> I don't care what style is used.
>>
>> Really, this is the sort of thing we should just enforce in a
>> commit hook.  At which point it doesn't matter what your editor
>> does.
>>
>> - ajax

Paulo




More information about the xorg mailing list