[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 05 Apr 2015 21:29:54 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style
On 2015-04-05 19:02, Solar Designer wrote:
> On Sun, Apr 05, 2015 at 03:22:47PM +0200, magnum wrote:
>> On 2015-04-05 14:04, Solar Designer wrote:
>>> 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 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.
>
> OK, I see the problem. I think moving away from 8 char tabs is the
> worst solution. I think it's better to allow for lines longer than 80
> chars in jumbo (perhaps 132), or to use spaces only (no tabs at all).
FTR: I don't see a problem with any of these.
> 8 char tabs are the default in many places, including e.g. when I view
> text files with "less" or john-dev postings in "mutt", or when my web
> browser renders a <pre>...</pre> block or a text/plain web page (perhaps
> from CVSweb or GitHub).
>
> If you use tabs only, then non-standard tab width is acceptable.
> If you use tab to indent, space to align - as you wanted to - then
> non-standard tab width is unacceptable. This gives us another option:
> switch to non-standard tab width, but give up on using space to align.
Perhaps there is a misunderstanding in regard to alignment. I can see
two cases:
1) alignment of things in lines with the same indentation, like this
(paraphrasing your example from the old thread):
if (crk_methods.cmp_one(pw->binary, index) &&
crk_methods.cmp_exact(pw->source, index) &&
crk_process_guess(salt, pw, index))
2) alignment of things in lines with different indentation, like
comments in
if (a) /* check this... */
if (some long expression) /* ...and that */
Given that magnum mentioned http://emacswiki.org/emacs/SmartTabs
earlier, I guess magnum means the first case. You probably mean the
second one.
The idea is use tabs in such a way that everybody can choose his
preferred tab size without any coordination with others and get intended
indentation and alignment. And I'm not sure what tab size discussion is
about at all. About the case 2) above? Let's just don't do it then.
The only real thing we cannot easily ignore is line width. Perhaps we
should limit it like this: "no more than 132 chars with 8 char tabs and
no more than 120 chars with 4 char tabs".
>>> 8 char tabs are used in Linux kernel, and in many *BSD's KNL
>>> http://en.wikipedia.org/wiki/Kernel_Normal_Form
>>
>> They also decide their name space. We can't.
>>
>> Also, no matter what you and I say or want, virtually everyone that
>> contributes to Jumbo DO use 4 or smaller, and I'd rather not complain
>> too much about it (risking just ending up with less contributions). If
>> we say 4, we might get away with enforcing it.
If we want consistent style we have to enforce it. It can be delayed
reformatting contributions later but it should be done anyway.
OTOH if it's easy to reformat the code than we can ask contributors to
do it before preparing a patch. This requires two things:
1) an easy way to make your code comply with our style guide by using a
script or specific indent(1) invocation;
2) existing code already complying with our style guide to exclude noise
from the patch.
> If you insist on this, then please ensure there won't be any use of
> space characters (simply don't align things at all). Tabs only. Then I
> will be able to simply use a wider terminal window and not care what tab
> width others editing the file meant to use. Since this effectively
> exceeds 80 chars anyway, I don't see much difference between this option
> and simply allowing e.g. 132 chars, except that this option forbids use
> of spaces and any kind of alignment. Maybe that's good.
Do you talk only about the case 2) above? Space characters in the case
1) seem not to pose any problem.
--
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.
