| Thread Previous • Date Previous • Date Next • Thread Next |
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 macros. 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.
Wayne
| Thread Previous • Date Previous • Date Next • Thread Next |
