Formatting of bootscripts

Ian Molton spyro at f2s.com
Tue Jan 4 16:47:06 PST 2005


Igor Zivkovic wrote:
> Archaic wrote:
> 
>>Please voice your opinions, suggestions, etc.
> 
> 
> This thread will probably turn into a religious flamefest but I think
> using tabs for indentation and spaces for alignment would be a fair
> compromise.

Thats actually exactly what I do. I disagree that its a compromise thoguh.

Consider (unformatted, although mozilla might 'help' me there)...

int some_fn(void){
	for(i = 0 ; a<b ; i+=c){
		printf("A %s of %d Characters in length", "string", length);
		dosomething();
	}
	printf("done it all\n");
	return -78;
}

The first printf() may run over the edge on some peoples displays so in 
order to make the code clearer for them whilst avoiding compromise to 
others, its nice to split the line and align the end under the previous 
line, at the same indentation level, eg.

		printf("A %s of %d Characters in length",
		"string", length);

However I feel this looks ugly and prefer to align the parameters such 
that they are under the parameters of the first line. a tab is not 
appropriate for this since the two lines are at the same conceptual 
level of indentation - they are both within the for{} loop, within the 
function some_fn().

The correct way to align the string is to use two tab characters (the 
same elvel of indentation as the preceeding line), and then use spaces 
to align the parameters - this causes the text to format correctly in 
all (reasonable) circumstances.

eg.
		printf("A %s of %d Characters in length",
		       "string", length);

ie. with two tabs on the first line, and the second, but 7 additional 
spaces on the second line.

if a third tab had been used, the second line would become unaligned 
should someone change their tabwidth. if spaces were used throughout, 
changing the 'tabwidth' would be impossible.

thus, I cannot agree that the idea of using tabs to indent and spaces to 
align is a compromise - it is, in fact, the one method that works 
universally - even in diffs!



More information about the lfs-dev mailing list