[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 05 Apr 2015 20:28:06 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
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:
http://thread.gmane.org/gmane.comp.security.openwall.john.devel/584
http://www.openwall.com/lists/john-dev/2011/07/14/9
>> 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 http://www.openwall.com/lists/john-dev/2011/07/15/2 ):
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.
