On Saturday 17 of January 2015 15:59:19 Sl�vek Banko wrote:
> On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
> > >> Also on the docket are how to handle simple variable assignments;
> > >> there are several ways I've seen: a=2; a = 2; a=
> > >> 2; a =2;
> > >>
> > >> I'm fairly undecided on this. �For consistency with larger statements
> > >> "a = 1;" should probably be used but it seems
> > >> such a waste of space compared with "a=1;". �Thoughts?
> > >
> > > Both "a=1" and "a = 1" are fine for me. For long time I used the first
> > > way, but in the last couple of years I switched
> > > ti the second one: usually more readable for simple expressions but can
> > > become confusing with long and complex ones
> > > such as:
> > > if ((a = 2) && (++b != (c + (x * y) / f(q,w,e))))
> > > Choice is up to you and Slavek.
> >
> > I'm going to lean towards forcing spaces for consistency. �What is your
> > opinion Slavek?
>
> Yes, with spaces - in my view certainly readable.

Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad.
I prefer to continue the discussion here.

I would say that there already was a consensus regarding spaces in the 
assignments - ie "a = b + c" and already there was a consensus regarding 
spaces around operators in conditions such as if, while - ie "if (a == b)".

All was fine until we had a case of 'for'. At its core, it does not contain 
anything new - uses the assignment and uses conditions => for both there 
already was a consensus. So one would expect that there is no problem.

Michele proposed:
for (i = 0; i < 1; i = i + 2) {
}

advantage - is fully in line with already agreed practices
disadvantage - are harder to distinguish the individual 'for' expressions


Tim proposed:
for (i=0; i<1; i=i+2) {
}

advantage - are well distinguishable individual 'for' expressions
disadvantages
 - difficult to read individual 'for' expressions as such
 - is inconsistent with already agreed practices


I understand Tim's argument. But that we would either to 'for' give exemption 
from other rules - which does not sound too good, or we would have to change 
already agreed rules - which is even worse option. I really would not want to 
because of the 'for' reduce the readability of all other conditions and 
assignments.

But there is another thing - more complex 'for' where individual parts can 
contain more assignments and more conditions - in such cases Tim's argument 
will be less important - on the contrary will be greater problem reduced 
readability each expressions as such.


Therefore I have two proposals:

1) As with the 'if' use 'excessive' brackets:

  for ((i = 0); (i < 1); (i = i + 2)) {
  }

2) More complex 'for' break into lines:

  for ((i = iteratorInicialization(arg));
       (i != iteratorEnd(arg));
       (i = iteratorNext(arg))) {
  }

What do you think about that?

-- 
Sl�vek