Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 11:13:11 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style

On 2015-07-27 05:08, Kai Zhao wrote:
> Hi magnum,
>
>> On Sat, Jul 25, 2015 at 10:41 PM, magnum
>> <john.magnum@...hmail.com> wrote:
>>
>> On 2015-07-25 15:05, Kai Zhao wrote:
>>> 3.2.2 Do not add spaces around (inside) parenthesized expressions.
>>>
>>> This example is *bad*:
>>>
>>>          s = sizeof( struct file );
>>
>>
>> I never write it like that but maybe we should be more liberal here.
>
> In order to use a automated formatter, I think we should recommend
> the:
>
>          s = sizeof(struct file);
>

OK

>>> 3.2.4 When type conversion, add a space before '*'.
>>>
>>> E.g:
>>>
>>>          hostSalt = (cl_uint *) mem_alloc(SALT_BUFFER_SIZE);
>>
>>
>> I personally disagree. We should mandate NOT adding a space,
>> or just be liberal about it. Actually I always drop the space after
>> the paren too:
>>
>>          hostSalt = (cl_uint*)mem_alloc(SALT_BUFFER_SIZE);
>>
>> I think we should allow (not require) a space after the paren, and
>> either allow or require that there's space before the '*'.
>>
>
> Here, I do't know how to choose ? But, if we use 'indent', it will add
> a space before '*', and after ')'.
>
> indent -kr -i8 -ts8 -nlp -ci4 -nbbo -ncs -l80 -lc80 -bad -il0 test.c
>
>          hostSalt = (cl_uint *) mem_alloc(SALT_BUFFER_SIZE);
>

Yeah I can live with it.

>> Our code style should not be a programming tutorial. IMHO drop
>> all of chapter 6.
>>
>
> What do you think on 6.4 ?

OK I actually like that one.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ