-----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:
- As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 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:
- 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