On 09/01/2015 10:58 AM, Jakub Hrozek wrote:
On Mon, Aug 31, 2015 at 01:24:17PM +0200, Michal Židek wrote:
> On 08/31/2015 01:20 PM, Jakub Hrozek wrote:
>> On Mon, Aug 31, 2015 at 02:09:19PM +0300, Alexander Bokovoy wrote:
>>> On Mon, 31 Aug 2015, Lukas Slebodnik wrote:
>>>> On (29/08/15 14:33), Alexander Bokovoy wrote:
>>>>> On Fri, 28 Aug 2015, Petr Cech wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> I would like to ask you what you think about the initialization
of
>>>>>> iterative variables in forloops. I know that present code style
does not
>>>>>> allow it. But how I recognized, we use C99, and this feature is
here now.
>>>>>>
>>>>>> (example)
>>>>>> Instead of:|
>>>>>> |||# inti;
>>>>>> # for(i =0;...)|||
>>>>>> we could write:
>>>>>> ||# for(inti =0;...)|
>>>>>>
>>>>>> I see an advantage in limiting the validity of such variables.
That means
>>>>>> higher code readability. Disadvantages I searched but did not
find.
>>>>> What this misses is a use case of indexed searches where resulting
index
>>>>> value is used beyond the loop itself. By changing context of
variable
>>>>> declaration, you make variable inaccessible outside of the loop.
>>>>>
>>>> I would say it's exactly the purpose of this proposal.
>>>> To decrease scope of visibility so the index variable with short name
>>>> cannot be misused for different purpose.
>>> Huh? There are valid cases where you search for an element and then use
>>> it further in the code. The index is what you get as the result of the
>>> search, not a reference to the element. Sometimes you need an element's
>>> reference but in many cases you need an index.
>>>
>>> Reducing scope is fine if you understand the context but claiming
>>> 'misuse' is a bit too much here.
>>>
>>> I'd suggest adding this syntax recommendation to SSSD C coding style
>>> guidelines but add as well a bit of explanation on these two types of
>>> loop usage patterns.
>>
>> Then I would suggest not to use the generic "i" name, but a more
>> descriptive one for the variable.
>>
>> On a related note -- Michal, any progress on updating the code
>> guidelines?
>
> Yes, but I would prefer to update the coding guidelines after
> Petr finish the wiki refactoring, so that I will not be adding
> stuff under his nose.
>
> Michal
If you have time, can you help with reviewing Petr's wiki changes, then?
Ok, will do.
Michal