20 Jan
2015
20 Jan
'15
12:19 a.m.
On Sunday 18 of January 2015 03:58:34 Michele Calgaro wrote:
On 01/18/2015 02:24 AM, Slávek Banko wrote:
Yeah, it looks good! Simple and clearly visible.
Two spaces seem to me to be sufficient.
On Saturday 17 of January 2015 15:59:19 Slávek
Banko wrote:
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.
On Friday 09 of January 2015 23:33:01 Timothy
Pearson wrote:
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? >> 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. 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