[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2026dbd195987df1a03b10de789aa955@smtp.hushmail.com>
Date: Tue, 07 Apr 2015 18:01:11 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style
On 2015-04-07 14:45, Kai Zhao wrote:
>> 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[*].
>
>> Also, I think we should document that we use "tab for indent, space for
>> align" as in http://emacswiki.org/emacs/SmartTabs.
>
> Do you prepare to kill the rule "tab for indent, space for align" ?
On the contrary I said I'm prepared to kill FOR it. Not literally of
course - if it turns out I'm the only one here that understands the
beauty of "tab for indent, space for align", I can live with not
aligning at all (that is, just indenting one (1) more level).
>> I can relate to that and for core this is a good decision. But in Jumbo
>> we live with lots of external things: Macros like
>> CL_DEVICE_PREFERRED_VECTOR_WIDTH_CHAR and functions like
>> clCreateProgramWithBinary(). Not to mention AMD's ADL. We get crazy
>> long lines without writing code that should be split to more functions.
>> Actually for OpenCL host code I often just give up and let it span
>> several lines.
>
> Do you think we can solve this problem by allowing to exceed column 80
> in such cases while the tab-width is still 8-character?
I think we should tell whatever indent-like program we end up using,
that we use a tab width of 4 and prefered max-width of 80-columns. Then
for a tab width of 8, we'll exceed 80 by some amount that will not
likely end up more than Solar's suggested 132.
magnum
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.
