Breaking lines in function headers

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

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

Quoted 2 lines · Dan Carpenter

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.

Quoted 5 lines

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?

Quoted 6 lines · Wim de With

Quoted 2 lines · Dan Carpenter

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.

Quoted 8 lines

Quoted 5 lines

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

Quoted 20 lines · Dan Carpenter

Quoted 6 lines · Wim de With

Quoted 2 lines · Dan Carpenter

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.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 2 lines

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.