← Back to team overview

kicad-developers team mailing list archive

Re: Code Style (Re: Graphics Abstraction Layer)


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

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.


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:)


Thanks ..

Follow ups