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