trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: January 2015

Re: [trinity-devel] Codebase formatting discussion

From: Michele Calgaro <michele.calgaro@...>
Date: Thu, 01 Jan 2015 21:31:04 +0900
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

<snip>
>> Just one quick comment; I still need to carefully review your
>> other suggestions and comment on them later:
>> 
>> Detached braces are a big problem for me, severely reducing code 
>> legibility.  Is this something you are flexible on or is code
>> like this:
>> 
>> void foo() { // Do stuff }
>> 
>> hard for you to read?
>> 
>> Thanks!
>> 
>> Tim
>> 
> 
> In this respect, my sympathy are for the Michele proposal.
> 
> For me parentheses at the end of the line are "invisible". For me,
> the better when I see both brackets incised in the same column than
> when losing at end of a line. When I need to quickly see the
> beginning of the block, easier to see clear bracket than "some"
> text as if, else, while, for, function name,... just something
> ambiguous.
> 
> Just my two cents.
> 

In my programming carrier I have worked with different styles with
different people, so if needed I can adapt to a different style and in
general I am flexible. Whatever consistent style is better than "no
style". The "attached brackets" vs "detached brackets" styles are two
"schools of thoughts", so no wonder that if someone is used to one way
he will find the other one harder to read, at least until he gets used
to it.
Having said all that, Slavek's comments described exactly my view on
the bracket point: brackets at the end of the line are harder to find
when scrolling along long blocks.

I guess there is no easy solution, either we choose one way or the
other. A possible way to mitigate the problem for the developers of
the other school of thought could be the following (a little awkward
but I haven't found anything better yet):
1) we create two (or more) style files and respective beautify files,
for example one for attached brackets and one for detached brackets.
The more options are in common between the two styles the better
2) we choose as "official style" the one most developers are happy with.
3) the developers of the other school can still use their style to
edit code locally before committing using these steps:
  a) git pull
  b) beautify_to_the_style_I_like.sh
  c) edit, compile, test locally until happy
  d) beautify_to_TDE_official_style.sh
  e) commit

It's a little bit uncomfortable, but at least its a possible way of
working with one's own favorite code style.
Note that point d) should become mandatory for all developers before
any commit, to make sure the code style is maintain over time.

Other ideas?

Cheers
  Michele
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUpT4IAAoJECp1t8qK3tXP8OcP+wT7+J2e/qYpCMURaT/AXWqK
Q3Rc8amomEbjlyWEz6yJvdf+crwBUhQTq3krDAxUYkPv3t1ubh8VAes4KsuSJMeI
qwJS+spAGTkww4LepXDjeinyeks8AeK1tzrI3BQ2OHXV0O4swUuR0KXQe3flqDI3
TGSGkkmcs7dapXeM1OB9bDnBwDZOlbuPqCmbpm/kAYRVHgWV4aGIVlgjN/TTcfFg
Lh9ezPCZWxY7a3zkQ2n6cnz37gPGjOeTeDsSmYRR4ChQBqKvYSWxDbDDqUcGJ4kx
MXOjBrwHFgrU7AEDm/SmHDyuKT4Vf4AG7KrekI5xogcXKk5ydctCVX6f1uLcNaq2
ZW9PpoGWtCoP6j0/IpQt2inqC9RIc+qSoyFykQ3aQN+cPt3jHY78uFl49bYqCqcb
47GpS5ZgC1JqKC/71sXg/QHMFyGRc7yBbDv1yK0Zcl/+webiog6N9y6Yw15TGoPt
0f+bvh5tfoueteqa84hCu1JLVcx66aU7YM9zggpBvPeSjVkuEKkxL7hgrjl09/yB
sAARBrAQkGlrXcGqniKiIMtfTe3F2fyQlHTRV0faTiSluOibXyoI4InAm/SARevG
qETgx+StxDL6sZp3e5beFltakd/hvH3SGP/i/eSMTYccEoz10cap8vV/KDpTZ8Ei
y1VJpip2WF2t6O6sRXkL
=Xk7r
-----END PGP SIGNATURE-----