Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 05 Apr 2015 20:28:06 +0300
From: Alexander Cherepanov <>
Subject: Re: Coding Style

On 2015-04-05 15:04, Solar Designer wrote:
> On Sun, Apr 05, 2015 at 12:43:23PM +0200, magnum wrote:
>> On 2015-04-05 12:02, Solar Designer wrote:
>>> As discussed before, this is about the closest match to what we need:
>>> 	indent -kr -i8 -nlp -nbbo -ncs -l79 -lc79
>>> although I dislike a few things about it - e.g., how it indents goto
>>> labels.  Oh, and IIRC our fmt_main struct initializers are mangled by
>>> this really bad.
>>> Maybe we should patch indent(1) for our use?
>> I think GNU indent has more options that are applicabe to us, than the
>> most basic variants. I *think* I could get around the struct issue but I
>> don't have any notes left from that. Someone should investigate what can
>> be used (and we should list it as an alternative for GNU indent only)
> I think it'd be helpful if you or Kai or someone else investigates this
> and posts in here.  The ideal indent program and its options would
> produce results close to the current formatting of the core tree.

BTW, the previous discussion is here:

>> BTW I am tempted to officially have Jumbo deviate from core's tab width
>> recommentdation, using 4 instead of 8. With the "indent with TABs, align
>> with spaces" requirement (which I'm prepared to kill for) this only
>> affects how long a line gets[*]. It seems to me absolutely no-one use 8
>> (except I use to do it when working with John - but I'm about to give
>> that up) so many lines are committed that did not exceed column 80 with
>> the author's TAB setting but do when 8 is used.
> I use 8 char tabs, and I like them.  In early 1990s, I used to prefer
> indentation with a few spaces (2 or 3), but later I realized that if I
> need so many indentation levels that 8 char tabs start being a problem
> (push lines beyond 80 chars), this usually means that the code needs to
> be refactored (usually split into more functions).

I don't think such issues could be discussed in isolation. One of the 
peculiarities of your style is the absence of indent in the following 
code (from ):

   for (i = 0; i < 10; i++)
   for (j = 0; j < 10; j++)
   for (k = 0; k < 10; k++) {
   	... body ...
	... body ...

This compensates for wide tabs to some degree. But I find this approach 
very strange. Surely, the example above looks nice. But your next example:

   for (i = 0; i < 10; i++)
   if (ok(i))
   while (j))
	... body ...
	... body ...

doesn't look better without indentation.

And combined with the fact that there are fragments like this:

   for (pos = &ciphertext[4]; atoi16[ARCH_INDEX(*pos)] != 0x7F; pos++);
   if (*pos || pos - ciphertext != 20) return 0;

it greatly undermines the usefulness of indentation -- you cannot be 
sure anymore where a block ended without fully parsing all the code. I 
think the principle that you can find the end of the block just by 
mentally drawing a vertical line until you meet something with less or 
equal indentation overweights the usefulness of alignment like the first 
example above.

I consider this issue much more important than tab size.

Alexander Cherepanov

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.