Re: [trinity-devel] Codebase formatting discussion

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.