03-02-2017, 11:23 AM
Yes, I understand that it is hard for automatic tools to figure out what is going on when definitions are not exact, and that my view would introduce such blurriness here.
I firstly read the rule from a human standpoint, and in a code review, I would ask: "Why don't you modify your loop counter in expression?".
Nevertheless, I am happy with the other view as well. Let's see the options:
---
The second point I objected, however, is that adding ++x to the first loop, as it was proposed, still does not make a valid example for 6-5-3, because the return value of modify() is boolean. Unless the inner logic of modify() is seen sufficient to satisfy the requirement of a relational operator.
I firstly read the rule from a human standpoint, and in a code review, I would ask: "Why don't you modify your loop counter in expression?".
Nevertheless, I am happy with the other view as well. Let's see the options:
- x is considered a loop counter. Then it is modified elsewhere, so rule 6-5-3 applies.
- x is not a loop counter. Then rule 6-5-1 applies which requests one.
- ++x is amended in expression, so x becomes a loop counter and the first case applies. So it fixes the code example ;-)
---
The second point I objected, however, is that adding ++x to the first loop, as it was proposed, still does not make a valid example for 6-5-3, because the return value of modify() is boolean. Unless the inner logic of modify() is seen sufficient to satisfy the requirement of a relational operator.
<t></t>