Breaking lines in function headers

Breaking lines in function headers

[Wim de With]

What is the correct way to break lines in a function header? The coding
style guide is not very clear about it. For example:

1.
static struct very_long_struct_name
*do_something_interesting(struct *another_long_struct_name)

2.
static struct very_long_struct_name *do_something_interesting(
				struct *another_long_struct_name)

Which one of these is the correct way to do it? I see the second one
used more often, and the coding style guide states "Descendants are
always substantially shorter than the parent and are placed
substantially to the right. The same applies to function headers with a
long argument list.", so I am inclined to say it is the correct way of
doing it. But if it is, how many tabs should I use? How should I align
the arguments if the list is longer, and I need more line breaks?

Thanks

Wim

Re: Breaking lines in function headers

[Julia Lawall]

On Tue, 19 May 2015, Wim de With wrote:

> What is the correct way to break lines in a function header? The coding
> style guide is not very clear about it. For example:
>
> 1.
> static struct very_long_struct_name
> *do_something_interesting(struct *another_long_struct_name)
>
> 2.
> static struct very_long_struct_name *do_something_interesting(
> 				struct *another_long_struct_name)

I don't recall ever seeing the second one.  But perhaps one doesn't see
what one doesn't look for.  In the first one, it seems odd to separate the
* from the rest of the return type.  I would think it would be very easy
to miss/misinterpret alone before the function name.

julia

> Which one of these is the correct way to do it? I see the second one
> used more often, and the coding style guide states "Descendants are
> always substantially shorter than the parent and are placed
> substantially to the right. The same applies to function headers with a
> long argument list.", so I am inclined to say it is the correct way of
> doing it. But if it is, how many tabs should I use? How should I align
> the arguments if the list is longer, and I need more line breaks?
>
> Thanks
>
> Wim
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Breaking lines in function headers

[Dan Carpenter]

On Tue, May 19, 2015 at 4:22 PM, Wim de With <nauxuron@wimdewith.com> wrote:
> What is the correct way to break lines in a function header? The coding
> style guide is not very clear about it. For example:
>
> 1.
> static struct very_long_struct_name
> *do_something_interesting(struct *another_long_struct_name)
>
> 2.
> static struct very_long_struct_name *do_something_interesting(
>                                 struct *another_long_struct_name)
>
> Which one of these is the correct way to do it? I see the second one
> used more often, and the coding style guide states "Descendants are
> always substantially shorter than the parent and are placed
> substantially to the right. The same applies to function headers with a
> long argument list.", so I am inclined to say it is the correct way of
> doing it. But if it is, how many tabs should I use? How should I align
> the arguments if the list is longer, and I need more line breaks?

First of gmail always marks your emails as spam so I only see the
replies.

Both declaration formats are acceptable.

These days instead of "substantially to the right" most people
insist that they be aligned.  I think checkpatch.pl --strict enforces
this.

regards,
dan carpenter

Re: Breaking lines in function headers

[Wim de With]

On 19-5-2015 16:08, Dan Carpenter wrote:
> First of gmail always marks your emails as spam so I only see the
> replies.

That might be because of my SPF/DMARC configuration. I think it's fixed now.

> Both declaration formats are acceptable.
> 
> These days instead of "substantially to the right" most people
> insist that they be aligned.  I think checkpatch.pl --strict enforces
> this.

So as long as I use the same style consistently in a source file, I'm good?

Wim

Re: Breaking lines in function headers

[Dan Carpenter]

On Tue, May 19, 2015 at 05:14:49PM +0200, Wim de With wrote:
> On 19-5-2015 16:08, Dan Carpenter wrote:
> > First of gmail always marks your emails as spam so I only see the
> > replies.
> 
> That might be because of my SPF/DMARC configuration. I think it's fixed now.
> 
> > Both declaration formats are acceptable.
> > 
> > These days instead of "substantially to the right" most people
> > insist that they be aligned.  I think checkpatch.pl --strict enforces
> > this.
> 
> So as long as I use the same style consistently in a source file, I'm good?
> 

I'm slightly confused what you mean.  If you're asking if you should
redo the visorchipset.c patch then don't bother with that.  The original
code is fine.

regards,
dan carpenter 

Re: Breaking lines in function headers

[Wim de With]

On 19-5-2015 17:20, Dan Carpenter wrote:
> On Tue, May 19, 2015 at 05:14:49PM +0200, Wim de With wrote:
>> On 19-5-2015 16:08, Dan Carpenter wrote:
>>> First of gmail always marks your emails as spam so I only see the
>>> replies.
>>
>> That might be because of my SPF/DMARC configuration. I think it's fixed now.
>>
>>> Both declaration formats are acceptable.
>>>
>>> These days instead of "substantially to the right" most people
>>> insist that they be aligned.  I think checkpatch.pl --strict enforces
>>> this.
>>
>> So as long as I use the same style consistently in a source file, I'm good?
>>
> 
> I'm slightly confused what you mean.  If you're asking if you should
> redo the visorchipset.c patch then don't bother with that.  The original
> code is fine.
> 
> regards,
> dan carpenter 

Yeah, I realized that already, but I saw some other files in
drivers/staging that had lines over 80 characters long, so I just wanted
to know how to do it correctly the next time I submit a patch like that.

Wim

Re: Breaking lines in function headers

[Dan Carpenter]

On Tue, May 19, 2015 at 05:26:21PM +0200, Wim de With wrote:
> On 19-5-2015 17:20, Dan Carpenter wrote:
> > On Tue, May 19, 2015 at 05:14:49PM +0200, Wim de With wrote:
> >> On 19-5-2015 16:08, Dan Carpenter wrote:
> >>> First of gmail always marks your emails as spam so I only see the
> >>> replies.
> >>
> >> That might be because of my SPF/DMARC configuration. I think it's fixed now.
> >>
> >>> Both declaration formats are acceptable.
> >>>
> >>> These days instead of "substantially to the right" most people
> >>> insist that they be aligned.  I think checkpatch.pl --strict enforces
> >>> this.
> >>
> >> So as long as I use the same style consistently in a source file, I'm good?
> >>
> > 
> > I'm slightly confused what you mean.  If you're asking if you should
> > redo the visorchipset.c patch then don't bother with that.  The original
> > code is fine.
> > 
> > regards,
> > dan carpenter 
> 
> Yeah, I realized that already, but I saw some other files in
> drivers/staging that had lines over 80 characters long, so I just wanted
> to know how to do it correctly the next time I submit a patch like that.

Sure.  Go for it.  Even if you mess up, staging is basically a friendly
place and we are used to newbies.

regards,
dan carpenter