kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Wayne,

Thanks again for your catching this.

I want to mention again that your diplomatic approach to this posting is 
very professional. 

I am part of another project, and that other project uses tabs. It may 
be that one of my recent commits had some tabs in it inadvertently 
because of a setting in my editor that did not get changed back for use 
with Kicad. If that happened, please understand it was not intentional.

It is still my desire to use spaces for indenting for this project, and 
this is in the uncrustify.cfg file as you astutely point out, put there 
deliberately by ME.

That other project cannot capture my long term loyalty, tabs are a 
partial reason.

Thanks for *your* fine help in this project. Maybe we should elect you 
as our foremost diplomat.

Dick


> 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.
>
> Wayne
>
>
> ------------------------------------
>
> Yahoo! Groups Links