Dne �t 20. ledna 2015 Timothy Pearson napsal(a):
> > On Sunday 18 of January 2015 03:58:34 Michele Calgaro wrote:
> >> On 01/18/2015 02:24 AM, Sl�vek Banko wrote:
> >> > 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?
> >>
> >> The excessive brackets are a possible solution, but on the other hand
> >> are a
> >> little "too excessive" IMO. What about the following ideas:
> >>
> >> 1) use two or three spaces to separate for statement expressions, as in:
> >>
> >> for (i = 0;  i < 1;  i = i + 2) {
> >>
> >> or
> >>
> >> for (i = 0;   i < 1;   i = i + 2) {
> >>
> >> This should be relatively easy to read, maintain all conventions and
> >> does
> >> not require excessive/superfluous parenthesis.
>
> <snip>
>
> Sorry to be the odd one out here but that is rather difficult for me to
> read in addition to consuming a (IMHO) ridiculous amount of horizontal
> screen space.  I understand the rationale, but now picture that statement
> in a sea of code--the eye will tend to scan right past it making
> determination of indent level difficult among other issues.  Also, I have
> never seen this style in any other major project; please correct me if I
> am wrong. :-)
>
> I still need to go over this thread and respond to the other messages, but
> haven't had much time lately.
>
> Tim
>

Two spaces seem to me sufficient to good readability, while there was no 
violated clarity.

Writing assignments and conditions in the 'for' without spaces results in 
inconsistence style with herself. Or, if you propose to remove spaces in 
assignments and conditions in all code, will make hard to read all code.

For example - without spaces it simply disgust:

  for (x=1,y=5; x<10&&y>0; x++,y--) {
  }


with spaces It's not beautiful, but at least readable:

  for (x = 1, y = 5;  x < 10 && y > 0;  x++, y--) {
  }


Therefore, the use of two spaces seems to me the least painful.
Just my two cents.

-- 
Sl�vek