kicad-developers team mailing list archive
Mailing list archive
Re: Why ALL capital letters for classes and typedefs
On 6/23/2012 8:39 AM, Dick Hollenbeck wrote:
On 06/22/2012 05:55 PM, Alexander Lunev wrote:
I believe most developers agree to follow some project predetermined coding style policy...
According to the KiCad coding style policy, constants and macro names should be
comprised of all capital letters (it is common, that is OK). However, according to the
policy, classes and typedefs should be designated in the same way (all capital letters).
So it is easier to get confused while reading the source code, especially for developers
who get used to names written in all capital letters and implied as either constants or
As for me, wxSomeClass and kiSomeClass names are quite good ones. I think these examples
are still in conformance with the common convention. wx and ki are just prefixes to
highlight a subset of classes.
The kicad coding standards clearly state the classnames are to be uppercase.
I am quite certain that Wayne will go ballistic if this stops being enforced.
Get over it. That decision has been made, and I personally spent about $30,000 of my time
getting the code base this way.
In total there has probably been $70,000 spent on it, and about 45% of that is from Wayne.
So do you think you have a chance at making this case name argument? Not on this planet,
not in this project.
I don't know if I would go ballistic but I do know one thing I would not
do and that is convert code as it stands now to another coding standard
after all the time and effort I spent getting the original code into the
current format. The KiCad coding standards were agreed upon quite a few
years ago by the lead developers. At that time there were very few
other people involved in the project let alone willing to step up to the
plate and take on that task. So I volunteered and with the input of
Dick and JP set out to write to coding policy. The project has done
just fine since the project has adopted the coding policy and most of
legacy code has been revised to meet the policy. There are a few places
where the legacy code still hasn't been updated but that should be
getting fairly uncommon.
Coding standards whether you like them or not are important for two
reasons. The second most important reason is consistency. As stated in
the coding policy, the only thing worse than looking at code formatted
in a style that you don't like is looking at 10 different formats that
you don't like in the same source file. I think we can all agree on
that. The most important reason to follow coding standards is in order
to show respect of the work done by everyone who came before you. If
you can understand this, then understanding the consistency part is
mute. I hate the GNU coding standards but if I were to ever submit any
code to a GNU project, you can be rest assured that it would follow the
GNU coding standards without complaint. The reason I would do this is
that I respect the efforts of the developers of that project even if I
don't like there coding style.
I would like to propose an experiment. Join the Linux kernel mailing
list and publicly scold Linus about how much you don't like Linux kernel
coding style. Then sit back and wait for a response. I can assure you
that the response on this mailing list is positively docile compared to
what you would get on the Linux kernel mailing list.