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