kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Torsten Hüter wrote:
> Hi Dick,
>
> > The project is not a democracy. It is "closer to" a group of share 
> > holders at a stock holder's meeting. I say it is "closer to", and not 
> > exactly like, and this is accurate. Where it can deviate is when 
> > somebody just gets louder on a particular issue and the larger 
> > shareholders can back off a little. Jean-Pierre is the largest
> > shareholder.
>
> To a certain degree I'd agree with that. Still I think such details should be discussed, of course at the end the project leader (Jean-Pierre) has to decide.

Torsten,

JP has been slowly moving towards the coding style that Dick has 
proposed. Although I don't remember him making any statement, his 
actions would suggest that he does agree with it.

> > I don't make noise on it everyday, but I keep most of my powder dry for 
> > the style discussion. I chose the style, picked uncrustify & chose the 
> > uncrustify.cfg settings and beautified scores of source files. It would 
> > be impossible for anyone to be louder on this subject.
>
> OK, thus it's basically your own coding style.
>
> > This just shows what someone else likes, not what I like, and where we 
> > are trying to go in this project. After 29 years of writing C, C++ and 
> > Java (40+ hours per week), it is even remotely possible that I don't 
> > know what I like? (I once wrote a project like wxwidgets all by myself, 
> > a knock off of CommonView for OS2, so I do not stand in amazement at the 
> > style choices made by the Qt team.)
>
> I fully respect your career and your experience; but I have a slightly different opinion. Usually the coding convention is found as compromise and not just by an individual. I understand, that the opinion of a contributor like you has a higher value - simply because you're longer around here.
>
> There is in my opinion a simple reason for the style choice of the QT team; it's similar or even based on the Java coding convention. Java is the number one programming language at the university, this is what you're learning first - inclusive the coding convention. That means in future you'll see it for even more projects. Just compare the existing style guides for C++ on the web.
>
> Some details are of course matter of taste.

Try that argument when sending a patch for inclusion in the Linux kernel 
and see where that gets you:) I think there is a much larger and more 
fundamental issue at work here. It is consistency. I have stated 
before that Dick's coding style is not my favorite either although it's 
starting to grow on me. Experience has taught me that the only thing 
worse that looking a coding style I don't like is looking at 10 
different coding styles I don't like. After you've been staring at 
source code for hours on end, consistency matters. Dick hasn't simply 
been around here longer, he has made a lot of significant contributions 
to Kicad. I believe that only JP has contributed more code than Dick. 
Dick took on the task of creating the template for uncrustify giving the 
project a coding standard where before there was none. Since the 
project leader has moved towards this coding style, I think we can 
safely assume that this is the coding style for Kicad source. I have 
cleaned up most if not all of my work and continue to use this style for 
all new contributions. There is still lots of legacy code in various 
styles but it is slowly getting brought up to date. I wrote an initial 
draft of the coding style guidelines that I sent to Dick for review. 
Hopefully it will get included into the source tree soon so that there 
is no confusion about coding style.

> --
>
> > Thanks, it is more about the uncrustify.cfg settings. The easiest way, 
> > but not the only way, is to use uncrustify to at least learn the desired 
> > style.
>
> I've already set up Eclipse for this style; I'll have to see if everything works like the uncrustify settings (of course running uncrustify over the final code would be no big deal either). 
>
> > Wayne has prepared a coding style document and I am reviewing it now. 
> > Wayne is a *great* contributor to this project and he has my 
> > considerable respect.
>
> If possible - I'd like to see it too.
>
> > The biggest thing we'll have to button down on is to not use tabs, but 
> > rather spaces. Spaces are the standard here.
>
> No problem, that's just one click for me :)
>
> Anything with the exception of class names is fine for me. Here I'd like go my own way - because I see the following problems of all uppercase: 
> (a) Possible confusing with defines and constants 

Use of all upper case names for defines and constants is no less 
arbitrary than using them for class names. This is an argument I never 
understood even though I use upper case names for defines and constants. 
This is just another example of someone always doing it that way 
because it was more readable to them.

> (b) Inconsistency - the other projects that I know use mixed cases, this includes wxWidgets too. If there is really a requirement for all uppercase, refactoring the class names is for me a matter of a few minutes. Perhaps you have a strong motivation for using all uppercase that I don't see at the moment.
>
> I'd just cite from Geosoft's coding guide:
>
> "[..]
> 1. Any violation to the guide is allowed if it enhances readability.
> The main goal of the recommendation is to improve readability and thereby the understanding and the maintainability and general quality of the code. It is impossible to cover all the specific cases in a general guide and the programmer should be flexible.
>
> 2. The rules can be violated if there are strong personal objections against them.
> The attempt is to make a guideline, not to force a particular coding style onto individuals. Experienced programmers normally want to adopt a style like this anyway, but having one, and at least requiring everyone to get familiar with it, usually makes people start thinking about programming style and evaluate their own habits in this area.
> [..]"

3. When working on an open source project with a defined coding style, 
it is considered good form to make contributions using the project's 
coding style in order to maintain the consistency of the source tree for 
the mutual benefit of all the developers in the project:)

Wayne

> Thanks ..
> Torsten