kicad-developers team mailing list archive
Mailing list archive
New coding guidelines.
Wayne Stambaugh <stambaughw@...>
Mon, 29 Dec 2008 17:00:35 -0500
Thunderbird 18.104.22.168 (Windows/20081105)
I was reluctant to say anything when "CODING_GUIDELINE.txt" was
committed (R1472) because of the can of worms I knew it would open, but
I just spent more time than I care to fixing a merge conflict that was
nothing more than a formatting change against two lines of code that I
added to my repo. The formatting suggested in "CODING_GUIDELINES.txt"
is nothing like the formatting generated using uncrustify with the
current configuration file "uncrustify.cfg". I have been using
uncrustify on all the files I have been editing so the code that I
submit to Kicad is consistent. Are we in a transition to a new code
formatting style? Did I miss a discussion on the mailing list about
code formatting? Does "uncrustify.cfg" need to be updated to reflect
the newly proposed coding guidelines? I would like some feedback before
I spend a lot of time having to reformat all of my source code after
just getting comfortable using uncrustify and the coding style it generates.
Here is my two cents on the current proposal. The proposed style looks
disturbingly similar to the GNU coding standards. I will use them if I
have to but I will not be happy about it. I think Linus summed it up
best in the Linux kernel coding guidelines when he said "First off, I'd
suggest printing out a copy of the GNU coding standards, and NOT read
it. Burn them, it's a great symbolic gesture.". Of course being a K&R
coder myself, you can understand why I am not a big fan of the GNU
coding style. It also seems like a duplication of effort as Dick H.
submitted "uncrustify.cfg" all the way back in R188. It also appears
that most of Kicad's source code has been formatted this way so I am
guessing other developers besides myself and Dick are using it.
If we need to reach a consensus, I vote for using the current formatting
generated by uncrustify. One thing I suggest is we define a coding
style and stick to it. The only thing worse than editing source code
with coding style you don't like is editing source code with 10
different coding styles you don't like.