hipl-core team mailing list archive

[Diego Biurrun <diego@xxxxxxxxxx>]

On Sun, Aug 29, 2010 at 05:35:41PM +0200, Christof Mroz wrote:
> On Sun, 29 Aug 2010 17:12:38 +0200, Diego Biurrun <diego@xxxxxxxxxx> wrote:
>
>> This 8 characters idea is completely arbitrary and IMO not an improvement
>> at all.  Creating more and arbitrary rules is not good.
>
> I agree, but I saw some instances of code in HIPL using an indent of 8  
> spaces so I assumed that was the right thing to do... well in this case,  
> there's no need to change doc/HACKING I think.

Never assume that anything you see in HIPL is right just by virtue
of existing.

>>> @@ -553,6 +555,23 @@
>>>
>>> +            /* opening '(' on next line if no argument fits */
>>> +            yet_another_function_with_a_long_name
>>> +                    (a_function_with_a_long_name(NULL, &blah, 0xC0FFEE));
>>
>> This is not K&R style and completely counterproductive.  You destroy the
>> visual cue that a string followed by an opening parenthesis gives you -
>> in K&R style you immediately know it's a function call, now you don't
>> anymore.
>
> I prefer the "dangling" opening parenthesis too

I do not prefer it, on the contrary.

Maybe the following part of the HACKING document is in need of rephrasing:

  Long lines (>80 characters) should be broken at suitable places
  where doing so improves readability.

--->

  Long lines (>80 characters) should be broken at suitable places
  if and only if doing so improves readability.

Is the latter clearer?

Diego