-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iFYEARELAAYFAlS98YkACgkQLaxZSoRZrGFZBADgv/IxNQx4H+2lnu4eOsPD6ww4
XUfF5dy2VnusoADcDTNCSWOxtRJLmauXTBsdsTXvyjDA2qLzUxp4Bg==
=0E2H
-----END PGP SIGNATURE-----