Keith said:
Skarmander said:
Keith Thompson wrote: [snip]
Which is what vi does by default; it has separate settings for
tabstop
size and indentation level. If you think that's a bad idea, I won't
argue with you, but you will need to deal with code that was created
in vi.
Aha! I have avoided vi like the plague ever since I encountered it,
which is why I'm ignorant of this. This would explain the most common
reason for how tabs and spaces get mixed up (and yes, the ubiquity of
vi means you have to "deal with it").
I wouldn't say it's a "bad idea" on its own. It just doesn't mesh with
other approaches; none of the approaches that mix tabs and spaces
do. It's the most fragile way to do it, really. I can understand why
people who are used to this model would be reluctant to ever use tabs.
Many problems can be avoided by consistently using 8-column tabstops.
Even more problems can be avoided by not using tabs at all.
In the vi model (or classic typewriter model, if you prefer), the
latter looks like the sanest approach to me. Your formatting has no
chance of surviving any change in settings otherwise.
You seem to be implying that, if it weren't for vi's behavior, it
would make sense to use just tabs for indentation, and modify your
editor's tabstop settings so the code looks the way you want it to.
(Even if you're not implying that yourself, others have.)
This is basically what I'm saying, but with a caveat. See below.
But if your code assumes 4-column tabstops, wouldn't you have to
specify 4-column tabstops for *everything* you do with the file?
Here's the thing. My code *does not* assume 4-column tabstops. It assumes
that tabstops do not coincide, and *nothing more*. Or to put it another way:
I basically do not format my code except for inserting newlines at
appropriate points. Where I place my tabs is not a creative decision, it's
practically part of the syntax.
You may be thinking of code that tries to do fancy lining up of items,
whether with tabs or spaces or both. Here's a typical excerpt from a Win32
program, which particularly suffers from the "functions with argument lists
as long as your arm" problem (as well as many others we'll ignore here):
CONTEXT Context;
DWORD dwThreadId,dwNumBytesXferred;
HANDLE hThread;
HINSTANCE hinstKrnl = GetModuleHandle(__TEXT("Kernel32"));
MEMORY_BASIC_INFORMATION mbi;
hThread = CreateRemoteThread(hProcess,NULL,dwNumBytes +
sizeof(HANDLE),(LPTHREAD_START_ROUTINE)
GetProcAddress(hinstKrnl,"ExitThread"),
0,CREATE_SUSPENDED,&dwThreadId);
Your newsreader may reformat the above and prevent my point from coming
across (in a way), but in the above code tabs are used to line up the
declarations and the function call arguments. The declarations only line up
neatly if you use 8-column tab stops, however. If lining things up neatly is
a priority to you, you'd need to reformat the code when you change tab
columns or simply replace them with spaces and be done with it.
Here's how I would format that code:
CONTEXT context;
DWORD dwThreadId, dwNumBytesXferred;
HANDLE hThread;
HINSTANCE hInstKrnl = GetModuleHandle(__TEXT("Kernel32"));
MEMORY_BASIC_INFORMATION mbi;
hThread = CreateRemoteThread(
hProcess, NULL, dwNumBytes + sizeof(HANDLE),
(LPTHREAD_START_ROUTINE) GetProcAddress(hinstKrnl, "ExitThread"),
0, CREATE_SUSPENDED, &dwThreadId
);
This code will look fine regardless of your tabstop settings, unless lines
start to wrap. This in itself may be considered an argument against, or an
argument for letting word wrapping take care of itself and not break up long
lines artificially based on your screen size -- but most tools simply aren't
clever enough to word-wrap code in a pleasing manner, or even at all.
Note that only single spaces are used, to separate tokens. I'm also well
aware that using brace-style indentation for function argument lists is
unusual, but it works well for me (and yes, I use K&R bracing).
In vi, I can do ":set tabstop=4", but what if I want to view the file
with "less" or "more"? What if I want to print it, or run it through a
text-to-PostScript converter? What if it's only a few lines long, and I
just want to "cat" it? What if I want to let someone else view or edit
the file in his own environment? (Some of these examples are
Unix-specific, but I'm sure there are corresponding tools on other
systems.)
Well, in all those examples, the way the code looks (or rather the
indentation) would change if tabstops are different, but the key point in
this is that if you do this you're not supposed to care, no more than about
how your newsreader wraps this paragraph. The whole idea behind using tabs
as logical indentation is that a tab only means "one level of indentation
deeper".
In my own work, I've usually used tools that allow me to specify
tabstops, but I've never felt the need to set them to anything other
than 8, and I'm having trouble understanding how you can deal with C
source code without a consistent tabstop setting.
I cannot deal with *other* people's source code if tabs are used in the
manner I initially described, no. If tabs and spaces are combined in some
way to produce code that neatly lines up, then you have to communicate your
tab stops to the other side or things will break. Hence, if you do this, you
are practically morally obliged to not use any tabs and replace them with
spaces on saving.
S.
