This was not mentioned before.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
---
 docs/coding-style.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/coding-style.rst b/docs/coding-style.rst
index 14c5136398..e1ed34f764 100644
--- a/docs/coding-style.rst
+++ b/docs/coding-style.rst
@@ -600,6 +600,19 @@ calling another function.
         ...
     }
 
+Define variables on separate lines. This allows for smaller, easier to
+understand diffs when changing them. Define variables in the smallest
+possible scope.
+
+::
+
+  GOOD:
+    int x;
+    int y;
+
+  BAD:
+    int x, y;
+
 Attribute annotations
 ---------------------
 
-- 
2.31.1

On a Friday in 2022, Tim Wiederhake wrote:
>This was not mentioned before.
>
>Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
>---
> docs/coding-style.rst | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
>diff --git a/docs/coding-style.rst b/docs/coding-style.rst
>index 14c5136398..e1ed34f764 100644
>--- a/docs/coding-style.rst
>+++ b/docs/coding-style.rst
>@@ -600,6 +600,19 @@ calling another function.
>         ...
>     }
>
>+Define variables on separate lines. This allows for smaller, easier to
>+understand diffs when changing them. Define variables in the smallest
>+possible scope.
>+
>+::
>+
>+  GOOD:
>+    int x;
>+    int y;
>+
>+  BAD:
>+    int x, y;
>+

Please use longer variable names and initialize some too, to illustrate
it better, e.g.:

     int count = 0, nnodes;

Personally I don't mind:

   size_t i, j;

that much - even though removing one does cause churn, they are simple
to read.

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano

On 1/14/22 10:56 AM, Ján Tomko wrote:
> On a Friday in 2022, Tim Wiederhake wrote:
>> This was not mentioned before.
>>
>> Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
>> ---
>> docs/coding-style.rst | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/docs/coding-style.rst b/docs/coding-style.rst
>> index 14c5136398..e1ed34f764 100644
>> --- a/docs/coding-style.rst
>> +++ b/docs/coding-style.rst
>> @@ -600,6 +600,19 @@ calling another function.
>>         ...
>>     }
>>
>> +Define variables on separate lines. This allows for smaller, easier to
>> +understand diffs when changing them. Define variables in the smallest
>> +possible scope.
>> +
>> +::
>> +
>> +  GOOD:
>> +    int x;
>> +    int y;
>> +
>> +  BAD:
>> +    int x, y;
>> +
> 
> Please use longer variable names and initialize some too, to illustrate
> it better, e.g.:
> 
>      int count = 0, nnodes;
> 
> Personally I don't mind:
> 
>    size_t i, j;
> 
> that much - even though removing one does cause churn, they are simple
> to read.

I also don't mind combining simple things like that, but am willing to 
go full-isolated just for consistency's sake.

Since it's Friday and we're talking about personal preferences - I 
personally dislike the use of i and j (and anything else with a single 
letter) as variable names, because it makes using a text search for 
occurences pointless. Sure, longer variable names could also be a 
substring of something else, and any variable could be re-used 
elsewhere, but even then a search is mildly usable.

(On the other hand, sometimes a loop is just a loop and it takes too 
much brain capacity to think of a meaningful name for the index. I used 
to work with someone who always used "ii" and "jj" for generic loop 
indexes because they were then easy to search for with few false 
positives (well - "ascii", "skiing", and a surprisingly high number of 
other more obscure words, but still...) , and I internalized that 
practice myself. After having libvirt patches with that rejected a 
couple times, I unlearned and conformed to the hive :-))

On a Friday in 2022, Laine Stump wrote:
>Since it's Friday and we're talking about personal preferences - I 
>personally dislike the use of i and j (and anything else with a single 
>letter) as variable names, because it makes using a text search for 
>occurences pointless. Sure, longer variable names could also be a 
>substring of something else, and any variable could be re-used 
>elsewhere, but even then a search is mildly usable.

Well, you need to search for the word i instead of the letter i.

grep has the '-w' switch for that, or you can specify some boundaries:
    \bi\b
    \<i\>

vim searches for the word under the cursor with '*' by default

Surely other search tools have some equivalent.

>
>(On the other hand, sometimes a loop is just a loop and it takes too 
>much brain capacity to think of a meaningful name for the index. I 
>used to work with someone who always used "ii" and "jj" for generic 
>loop indexes because they were then easy to search for with few false 
>positives (well - "ascii", "skiing", and a surprisingly high number of 
>other more obscure words, but still...) , and I internalized that 
>practice myself. After having libvirt patches with that rejected a 
>couple times, I unlearned and conformed to the hive :-))

II thank you.

JJano

On 1/14/22 3:29 PM, Ján Tomko wrote:
> On a Friday in 2022, Laine Stump wrote:
>> Since it's Friday and we're talking about personal preferences - I 
>> personally dislike the use of i and j (and anything else with a single 
>> letter) as variable names, because it makes using a text search for 
>> occurences pointless. Sure, longer variable names could also be a 
>> substring of something else, and any variable could be re-used 
>> elsewhere, but even then a search is mildly usable.
> 
> Well, you need to search for the word i instead of the letter i.
> 
> grep has the '-w' switch for that, or you can specify some boundaries:
>     \bi\b
>     \<i\>
> 
> vim searches for the word under the cursor with '*' by default
> 
> Surely other search tools have some equivalent.

This forced me to go look for it in emacs, and after 28 years, I've 
learned about isearch-forward-symbol-at-point, which is by default bound 
to [alt-s .]. But that's just another different keystroke I have to 
remember. Much easier if I can just use an expansion of the ctl-s 
(incremental search) that I already know and use for pretty much all 
searching within a single file.

> 
>>
>> (On the other hand, sometimes a loop is just a loop and it takes too 
>> much brain capacity to think of a meaningful name for the index. I 
>> used to work with someone who always used "ii" and "jj" for generic 
>> loop indexes because they were then easy to search for with few false 
>> positives (well - "ascii", "skiing", and a surprisingly high number of 
>> other more obscure words, but still...) , and I internalized that 
>> practice myself. After having libvirt patches with that rejected a 
>> couple times, I unlearned and conformed to the hive :-))
> 
> II thank you.
> 
> JJano

KKind of you,

LLaine

On Sat, Jan 15, 2022 at 02:22 Laine Stump <laine@redhat.com> wrote:

> On 1/14/22 3:29 PM, Ján Tomko wrote:
> > On a Friday in 2022, Laine Stump wrote:
> >> Since it's Friday and we're talking about personal preferences - I
> >> personally dislike the use of i and j (and anything else with a single
> >> letter) as variable names, because it makes using a text search for
> >> occurences pointless. Sure, longer variable names could also be a
> >> substring of something else, and any variable could be re-used
> >> elsewhere, but even then a search is mildly usable.
> >
> > Well, you need to search for the word i instead of the letter i.
> >
> > grep has the '-w' switch for that, or you can specify some boundaries:
> >     \bi\b
> >     \<i\>
> >
> > vim searches for the word under the cursor with '*' by default
> >
> > Surely other search tools have some equivalent.
>
> This forced me to go look for it in emacs, and after 28 years, I've
> learned about isearch-forward-symbol-at-point, which is by default bound
> to [alt-s .]. But that's just another different keystroke I have to
> remember. Much easier if I can just use an expansion of the ctl-s
> (incremental search) that I already know and use for pretty much all
> searching within a single file.


Haha ! I use emacs as well and I never knew about this too. Will try it
too. Thanks!