On 31.03.2016 09:27, Gene Heskett wrote:
I believe the function of the code as committed is unchanged, but its
less than readable, and it would have to be verified by cntx, a
checking utility I wrote 25 or so years ago just to verify that
[]{}()""'' etc stuff was in fact matched. I also suspect that if the
compiler is working well, it would generate identical machine code
from that hard to read 2nd example. Which leaves the question: Why
force a hard to read, hard to check for errors etc format on the code
submitters? It contributes to hard to find & fix bugs. And for the
savvy coders, one of which already piped up about the brace locations,
it may make them reticent to submit what is a perfectly good patch.
I'd think discourageing potential submitters is pretty close to the
last thing you would want to do.
This is what uncrustify was supposed to solve.
By applying uncrustify on the original jack1 code plus the code with
Fons' patch (and then generating a diff),
we would, in theory, get rid of all the whitespace and style changes..
Either the uncrustify config is not 100% correct, or uncrustify itself
has issues.
In my opinion we should get back to the original jack1 code before
uncrustify messed up things.
And then try to generate a clean patch. I'm willing to do the clean
patch if Paul reverts uncrustify changes.
@Paul: is that ok?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
