I created a astylerc for automated coding style fixing.
Thanks for your effort!
After running this we have a lot changes:
209 files changed, 15148 insertions(+), 12980 deletions(-)
but the code is more readable and maintainable....
That's the general idea behind the coding conventions. However, in some
(rare) cases it might be beneficial not to stick too the coding conventions
too literal.
For example core/bitarithm.c
The current code is:
r = (v > 0xFFFF) << 4; v >>= r;
shift = (v > 0xFF ) << 3; v >>= shift; r |= shift;
shift = (v > 0xF ) << 2; v >>= shift; r |= shift;
shift = (v > 0x3 ) << 1; v >>= shift; r |= shift;
r |= (v >> 1);
astyle would convert it into:
r = (v > 0xFFFF) << 4;
v >>= r;
shift = (v > 0xFF) << 3;
v >>= shift;
r |= shift;
shift = (v > 0xF) << 2;
v >>= shift;
r |= shift;
shift = (v > 0x3) << 1;
v >>= shift;
r |= shift;
r |= (v >> 1);
In this case I would definitely prefer the non-cc (aka the current) version.
I can also create a pre commit hook to ensure this style!
In fact, a nice idea. I'm not an expert on git commit hooks. Is it possible to
configure these hooks in an optional manner? Or is there any way to declare
exceptions from the coding conventions for particular pieces within the code?
Anyway, I will browse through the entire suggestions of astyle and probably
apply most of the changes to the repository.
The current code is:
r = (v > 0xFFFF) << 4; v >>= r;
shift = (v > 0xFF ) << 3; v >>= shift; r |= shift;
shift = (v > 0xF ) << 2; v >>= shift; r |= shift;
shift = (v > 0x3 ) << 1; v >>= shift; r |= shift;
r |= (v >> 1);
astyle would convert it into:
r = (v > 0xFFFF) << 4;
v >>= r;
shift = (v > 0xFF) << 3;
v >>= shift;
r |= shift;
shift = (v > 0xF) << 2;
v >>= shift;
r |= shift;
shift = (v > 0x3) << 1;
v >>= shift;
r |= shift;
r |= (v >> 1);
In this case I would definitely prefer the non-cc (aka the current) version.
your example above isn't the default case, this is hand tuned bit operations... 99% of the code's styling is "just wrong" in terms of the style guide.
I can also create a pre commit hook to ensure this style!
In fact, a nice idea. I'm not an expert on git commit hooks. Is it possible to
configure these hooks in an optional manner? Or is there any way to declare
exceptions from the coding conventions for particular pieces within the code?
ah, I don't think so, not with astyle.
Anyway, I will browse through the entire suggestions of astyle and probably
apply most of the changes to the repository.
It appears the astyle does not adhere to our conventions when it comes to
spacing if-statements (if (foo) vs. if(foo)).
Hmm, too bad. I wasn't careful enough here. However, though Linux' coding
style proposes to use a space after keywords such as if, switch, case, for, or
while, I personally don't have any strong feelings for the one or the other
option. What about you? Would you agree to leave the code as it is (i.e.
without a space between these keywords and the opening parenthesis) and just
update the coding conventions? Or is there any strong reason to avoid this?
It appears the astyle does not adhere to our conventions when it comes to
spacing if-statements (if (foo) vs. if(foo)).
okay, let's obey the Linux coding conventions then. I fixed it in
c8bee9e554f58da3a74c7a40374064a1fbf9890f. However, I didn't figure out how to
tell astyle to do this. (In fact, sed was my friend.)
However, in some
(rare) cases it might be beneficial not to stick too the coding conventions
too literal.