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