Re: #define<TAB> in share/misc/style [was: CVS commit: src/share/misc]

[ On Sunday, March 2, 2003 at 13:31:13 (-0500), John Hawkinson wrote: ]
> Subject: Re: #define<TAB> in share/misc/style [was: CVS commit: src/share/misc]
>
> Greg A. Woods <[email protected]> wrote on Mon, 24 Feb 2003
> at 18:07:37 -0500 in <[email protected]>:
> >
> > I've never ever seen even the barest hint of reasonable rationale for
> > using a tab instead of a space beteen the "#define" and the macro name
> > which follows it.
> 
> Well, I believe the rationales are a) consistency

Consistency with what?  Existing invisible nothingness?  I.e. note that
visibly there's nothing to be consistent with -- both a tab and a space
in this situation normally have exactly the same look and feel!

> b) a desire to
> use TABs as a generalized seperator.

Which in this particular case is completely bogus.  We're talking about
C here, and in particular the C preprocessor syntax.  ASCII tab
characters are often used for indentation, not very often used as token
separators.  They really shouldn't even be used to align the macro
definitions, and comment blocks on the right-hand side of statements,
though so long as everyone uses the _standard_ 8-char tabstop settings
then these long-standing conventions are their only reasonable use.

I.e. TABs are rarely generalized as _separator_ characters, especially
not in C and CPP syntaxes, but rather are very special separator
characters which are only used to visually align columns to the right of
other text so that minor editing of the leading text won't require
manual realignment (and arguably so that runs of space characters can be
somewhat compressed too).

> b) doesn't hold a huge amount
> of weight, but it allows consistency with other kinds of syntaxes
> where spaces may not be the conceptual seperator.

We're talking about C here.  Why would anyone want to be consistent with
other syntaxes when they're writing C code?  Such a desire would simply
generate a direct, fundamental, and blatant inconsistency with the very
language the program is currently being expressed in!  I.e. why generate
a fundamental inconsistency just to provide a pseudo-consistency with
something that will not likely be generally relevant to all future
readers and maintainers?

> Personally, I have an irrational attachment to the use of tabs here,
> and would like to see a bit more inter-BSD consistency, but I don't
> think those reasons are strong enough here.

I'll tell you several reasons why the use of a tab as the separator
before a C preprocessor macro name is not just irrational, but often
quite annoying as well:

	1. it makes diff output look quite horrendous (i.e. much less
	   readable than it already is

	2. it makes adding of indentation for preprocessor statements
	   "difficult" -- i.e. this:

		#define	FOO	64

	   becomes (without manual realignment):

		#ifdef BAR
		# define	FOO	64
		#endif

	   Yuck.

	3. without indentation a TAB after "#define" is invisible,
	   i.e. indistinguishable from a normal space character, and
	   thus it cannot be visibly identified

-- 
								Greg A. Woods

+1 416 218-0098;            <[email protected]>;           <[email protected]>
Planix, Inc. <[email protected]>; VE3TCP; Secrets of the Weird <[email protected]>