kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne,
> 
> Thanks again for your catching this.
> 
> I want to mention again that your diplomatic approach to this posting is 
> very professional.

I approach working on Kicad the same way I would dealing with people at
work. I always try to give people the benefit of the doubt before I
beat them over the head. Believe me, I raked more than my fair share of
people over the coals. Sometimes it was justified and sometimes it wasn't.

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

I'm not a big fan of tabs myself. I hate having to change my setting to
get code line up correctly in my editor.

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

This definitely falls under the category of "Be careful what you wish
for". All joking aside, I just want to help make Kicad the best it can
be. I wish I could devote more time to the project. I use Kicad
professionally and want to give as much back as I can.

Wayne

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