We didn't specify the indent rule for multiline code here, which may
misleading users. And in current code, the code use different rules.

Add this rule in CODING_STYLE to make sure this is clear to every one.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
---
 CODING_STYLE | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index ec075dedc4..73f66ca185 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -29,6 +29,32 @@ Spaces of course are superior to tabs because:
 
 Do not leave whitespace dangling off the ends of lines.
 
+1.1 Multiline Indent
+
+There are several places where indent is necessary:
+
+ - struct definition
+ - if/else
+ - while/for
+ - function definition & call
+
+All the above cases apply the same rule: indent with four spaces.
+
+While the last three case may face another situation: code should spread into
+several lines. In this case the rule is align the new line with first
+parentheses.
+
+For example:
+
+    if (a == 1 &&
+        b == 2)
+
+    while (a == 1 &&
+           b == 2)
+
+    do_something(arg1, arg2
+                 arg3)
+
 2. Line width
 
 Lines should be 80 characters; try not to make them longer.
-- 
2.19.1

Hi,

On 2/19/19 2:31 AM, Wei Yang wrote:
> We didn't specify the indent rule for multiline code here, which may
> misleading users. And in current code, the code use different rules.
> 
> Add this rule in CODING_STYLE to make sure this is clear to every one.
> 
> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
> ---
>  CODING_STYLE | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index ec075dedc4..73f66ca185 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -29,6 +29,32 @@ Spaces of course are superior to tabs because:
>  
>  Do not leave whitespace dangling off the ends of lines.
>  
> +1.1 Multiline Indent
> +
> +There are several places where indent is necessary:
> +
> + - struct definition
> + - if/else
> + - while/for
> + - function definition & call
> +
> +All the above cases apply the same rule: indent with four spaces.
> +
> +While the last three case may face another situation: code should spread into
> +several lines. In this case the rule is align the new line with first
> +parentheses.
> +
> +For example:
> +
> +    if (a == 1 &&
> +        b == 2)
> +
> +    while (a == 1 &&
> +           b == 2)
> +
> +    do_something(arg1, arg2
> +                 arg3)

Thanks for clearing this.

What is still unclear is what to do when a function name is over 60
characters (you follow a library/API and can not shorten it), for example:

static void ccid_card_vscard_handle_message(PassthruState *card,
    const VSCMsgHeader *scr_msg_header);

What is the project guideline in this case?
(Cc'ed Peter).

> +
>  2. Line width
>  
>  Lines should be 80 characters; try not to make them longer.
> 

On 2/19/19 11:34 AM, Philippe Mathieu-Daudé wrote:

> 
> What is still unclear is what to do when a function name is over 60
> characters (you follow a library/API and can not shorten it), for example:
> 
> static void ccid_card_vscard_handle_message(PassthruState *card,
>     const VSCMsgHeader *scr_msg_header);
> 
> What is the project guideline in this case?

I don't know that we have an official guideline, but I've seen enough
code doing that. I've also seen this style:

static void long_func_name(
    parameter one, parameter two)
{
    if (condition) {
        call_some_really_long_name(
            arg1,
            arg2);
    }

where even the first argument is put at an indentation of 4 from the
primary line.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Tue, Feb 19, 2019 at 11:55:04AM -0600, Eric Blake wrote:
>On 2/19/19 11:34 AM, Philippe Mathieu-Daudé wrote:
>
>> 
>> What is still unclear is what to do when a function name is over 60
>> characters (you follow a library/API and can not shorten it), for example:
>> 
>> static void ccid_card_vscard_handle_message(PassthruState *card,
>>     const VSCMsgHeader *scr_msg_header);
>> 
>> What is the project guideline in this case?
>
>I don't know that we have an official guideline, but I've seen enough
>code doing that. I've also seen this style:
>
>static void long_func_name(
>    parameter one, parameter two)
>{
>    if (condition) {
>        call_some_really_long_name(
>            arg1,
>            arg2);
>    }
>
>where even the first argument is put at an indentation of 4 from the
>primary line.

We should put this style in the example too?

>
>-- 
>Eric Blake, Principal Software Engineer
>Red Hat, Inc.           +1-919-301-3226
>Virtualization:  qemu.org | libvirt.org

-- 
Wei Yang
Help you, Help me

On 2/18/19 7:31 PM, Wei Yang wrote:
> We didn't specify the indent rule for multiline code here, which may
> misleading users. And in current code, the code use different rules.
> 
> Add this rule in CODING_STYLE to make sure this is clear to every one.
> 
> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
> ---
>  CODING_STYLE | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index ec075dedc4..73f66ca185 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -29,6 +29,32 @@ Spaces of course are superior to tabs because:
>  
>  Do not leave whitespace dangling off the ends of lines.
>  
> +1.1 Multiline Indent
> +
> +There are several places where indent is necessary:
> +
> + - struct definition
> + - if/else
> + - while/for
> + - function definition & call
> +
> +All the above cases apply the same rule: indent with four spaces.

Is this redundant with the earlier statement that "QEMU indents are four
spaces."?

> +
> +While the last three case may face another situation: code should spread into
> +several lines. In this case the rule is align the new line with first
> +parentheses.

Grammar is awkward - the leading 'while' makes it sound like that you
have a dependent clause, but then never provide the independent clause.
Maybe a completely different wording is better:

When breaking up a long line to fit within line widths, align the
secondary lines just after the opening parenthesis of the first.

> +
> +For example:
> +
> +    if (a == 1 &&
> +        b == 2)
> +

Maybe:

if (a == 1 &&
    b == 2) {

to match our later recommendations on always using {}.

> +    while (a == 1 &&
> +           b == 2)
> +

Similar.

> +    do_something(arg1, arg2
> +                 arg3)
> +

and here, I'd include the ';' to make it a valid statement.

>  2. Line width
>  
>  Lines should be 80 characters; try not to make them longer.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Tue, Feb 19, 2019 at 11:52:29AM -0600, Eric Blake wrote:
>On 2/18/19 7:31 PM, Wei Yang wrote:
>> We didn't specify the indent rule for multiline code here, which may
>> misleading users. And in current code, the code use different rules.
>> 
>> Add this rule in CODING_STYLE to make sure this is clear to every one.
>> 
>> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>> Suggested-by: Igor Mammedov <imammedo@redhat.com>
>> ---
>>  CODING_STYLE | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>> 
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index ec075dedc4..73f66ca185 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -29,6 +29,32 @@ Spaces of course are superior to tabs because:
>>  
>>  Do not leave whitespace dangling off the ends of lines.
>>  
>> +1.1 Multiline Indent
>> +
>> +There are several places where indent is necessary:
>> +
>> + - struct definition
>> + - if/else
>> + - while/for
>> + - function definition & call
>> +
>> +All the above cases apply the same rule: indent with four spaces.
>
>Is this redundant with the earlier statement that "QEMU indents are four
>spaces."?
>
>> +
>> +While the last three case may face another situation: code should spread into
>> +several lines. In this case the rule is align the new line with first
>> +parentheses.
>
>Grammar is awkward - the leading 'while' makes it sound like that you
>have a dependent clause, but then never provide the independent clause.
>Maybe a completely different wording is better:
>
>When breaking up a long line to fit within line widths, align the
>secondary lines just after the opening parenthesis of the first.
>

Sounds better.

>> +
>> +For example:
>> +
>> +    if (a == 1 &&
>> +        b == 2)
>> +
>
>Maybe:
>
>if (a == 1 &&
>    b == 2) {
>
>to match our later recommendations on always using {}.
>

Yep.

>> +    while (a == 1 &&
>> +           b == 2)
>> +
>
>Similar.
>
>> +    do_something(arg1, arg2
>> +                 arg3)
>> +
>
>and here, I'd include the ';' to make it a valid statement.
>

Reasonable.

>>  2. Line width
>>  
>>  Lines should be 80 characters; try not to make them longer.
>> 
>
>-- 
>Eric Blake, Principal Software Engineer
>Red Hat, Inc.           +1-919-301-3226
>Virtualization:  qemu.org | libvirt.org

-- 
Wei Yang
Help you, Help me