kicad-developers team mailing list archive
Mailing list archive
Re: Code Style (Re: Graphics Abstraction Layer)
Wayne Stambaugh <stambaughw@...>
Sat, 27 Feb 2010 14:43:27 -0500
Mozilla-Thunderbird 22.214.171.124 (X11/20090706)
Torsten Hüter wrote:
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
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
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:)