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.
>

Yeah, it looks good! Simple and clearly visible.
Two spaces seem to me to be sufficient.

> 2) use one line for each for expression as in:
>
> for (i = 0;
>      i < 1;
>      i = i + 2) {
>

I have no objection to any of these methods.

>
>
> I also thought more about bracket position and came up with the following
> idea which is a mix of Tim's favorite style and mine/Slavek's favorite
> style.
>
>      if (foo)
>      {  a = 0;
>         b = 1;
>      }
>      else if (bar)
>      {  a = 1;
>         b = 2;
>      }
>      else
>      {  a = 2;
>      }
>
>
>     switch(foo)
>     {   case bar:
>         {   a = 1;
>             break;
>         }
>         case baz:
>         {   a = 2;
>             ...long case block...
>             c = 4;
>             break;
>         }
>         case asd:
>         {   a = 3;
>             break;
>         }
>         default:
>         {   a = 0;
>         }
>     }
>
> Basically, the only difference from Tim's style is that the opening bracket
> is detached and located in the following line, but the "space location" of
> the lines of code remains the same (no additional lines required only for
> the opening bracket). At the same time the opening and closing brackets are
> aligned, making easy to detect the beginning and ending of a block. What do
> you think? This is actually the first style I ever used many many many
> years ago :-)
>
> Cheers
>   Michele
>

Opening brace is on the front of the line, but its good visibility 
deteriorates text followed brace on the same line.
Although the style is very compact,
it seems to me less readable.

-- 
Sl�vek