-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

2) use one line for each for expression as in:

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



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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJUuyFaAAoJECp1t8qK3tXPGVQP/1BgHBxAO7/iv1Qtp8WTOZxy
KPJKVSB7RJereyf/SZAK2nzkuN8cP9CxMqTdVRUfut4f6kxcOK8uoSduSJDgpT9E
T9Gz80pRjwLqhTaNuouBqRUtbA6E+kfdVcgr1Ac8g9DypPbvNnsds/45AVrdrssg
pBM4xyhyJgib1WwX5/2tGZHHrW6jZUyvdW15Ox7u5Wgn6KaUrLR8Ssck2m442wJe
Eg9A+DPn0VlQU3Wdj1nclcUeFMbrDuqvoDop1Lg12uYZ3lixeIq22dnzvB/DR/YH
GvSTedZyAomfy+/G/RYhooaNol7RoXQRQO9zrxzRzCdBXQMjLM5iKR9taHuQP7Sw
LiWGK5lJTahLnpDYBn+7+yS7xW9F9McAgw7EUiPTvRK8AMGZfSgfgEmyPfdt1/Pd
FK3ifBpVCSpIL8dtfjSZ+hTFMlo2mmGOPFBBhtN15eCav4MLxYeA9IlJe1fSsNY1
jCSzDiN59pwzs9Z304mBEM+i1EClGjaVcRTGfRuQA6t8QTwqbcDiyCjmb4XgSvpl
nIUFHyxClSbQcfwS220kLGGcEWw7vhStKzrsOsjJLf2vNyECEvogkT+ytFp+yC2P
JOjpJ0m7BlH8CmIQ6J19DTIFs6Km0gcHtMiwWYYdMCPmR18CjP/uu8mm/ulxYzX/
fuwlyKz/yhAbhvHgXbQ7
=6CoW
-----END PGP SIGNATURE-----