Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Joe Perches
On Sat, 2018-05-12 at 19:07 +0300, igor.sto...@gmail.com wrote:
> On 12 May 2018 at 18:41, Joe Perches  wrote:
> 
> > 
> > I think the first style should be preferred when the
> > combined character length of   is
> > relatively long.
> > 
> 
> thank you, I could provide a patch to the docs for this case, if it's not
> considered too much of a corner case.

I think it should not considered anything like a mandate.

Perhaps it could be described as an optional/possible style
but perhaps as well it's not necessary as coding_style for
this does not have to be rigidly specified.

cheers, Joe


Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Joe Perches
On Sat, 2018-05-12 at 19:07 +0300, igor.sto...@gmail.com wrote:
> On 12 May 2018 at 18:41, Joe Perches  wrote:
> 
> > 
> > I think the first style should be preferred when the
> > combined character length of   is
> > relatively long.
> > 
> 
> thank you, I could provide a patch to the docs for this case, if it's not
> considered too much of a corner case.

I think it should not considered anything like a mandate.

Perhaps it could be described as an optional/possible style
but perhaps as well it's not necessary as coding_style for
this does not have to be rigidly specified.

cheers, Joe


Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Igor Stoppa

On 12/05/18 18:41, Joe Perches wrote:


I personally like more the former, not to mention that it uses also one
line less, but it seems less common in the sources.
The coding style references do not seem to say anything explicit about
which style to prefer.


thank you, I could provide a patch to the docs for this case, if it's 
not considered too much of a corner case.


--
igor


Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Igor Stoppa

On 12/05/18 18:41, Joe Perches wrote:


I personally like more the former, not to mention that it uses also one
line less, but it seems less common in the sources.
The coding style references do not seem to say anything explicit about
which style to prefer.


thank you, I could provide a patch to the docs for this case, if it's 
not considered too much of a corner case.


--
igor


Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Joe Perches
On Sat, 2018-05-12 at 18:19 +0300, Igor Stoppa wrote:
> I have been wondering if it's ok to break a long (function declaration) 
> line in the following way:
> 
> static __always_inline
> struct foo_bar *__get_foo_bar(type1 parm1, type2 parm2, type3 parm3)
> 
> 
> instead of:
> 
> static __always_inline struct foo_bar *__get_foo_bar(type1 parm1,
>type2 parm2,
>type3 parm3)
> 

I think so.

> I personally like more the former, not to mention that it uses also one 
> line less, but it seems less common in the sources.
> The coding style references do not seem to say anything explicit about 
> which style to prefer.

I think the first style should be preferred when the
combined character length of   is
relatively long.


Re: [RFC: Coding Style] Best way to split a long function declaration with modifiers

2018-05-12 Thread Joe Perches
On Sat, 2018-05-12 at 18:19 +0300, Igor Stoppa wrote:
> I have been wondering if it's ok to break a long (function declaration) 
> line in the following way:
> 
> static __always_inline
> struct foo_bar *__get_foo_bar(type1 parm1, type2 parm2, type3 parm3)
> 
> 
> instead of:
> 
> static __always_inline struct foo_bar *__get_foo_bar(type1 parm1,
>type2 parm2,
>type3 parm3)
> 

I think so.

> I personally like more the former, not to mention that it uses also one 
> line less, but it seems less common in the sources.
> The coding style references do not seem to say anything explicit about 
> which style to prefer.

I think the first style should be preferred when the
combined character length of   is
relatively long.