I also think it's much better for devs to check these things themselves; blindly relying on a tool to apply formatting could result in monstrous commits for trivial things. Maybe a better way now that we're using git is to have a pre-commit hook which checks and blocks a commit if the rules are violated. Some files will have to be exempt of course such as the autogenerated wx code.
- Cirilo On Tue, Nov 8, 2016 at 2:02 AM, Wayne Stambaugh <[email protected]> wrote: > On 11/2/2016 11:47 AM, Marvin Schmidt wrote: >> Hi everybody! >> >> I've been following the KiCad development for some time and I feel like >> quite some time is wasted on whitespaces. Be it either when new >> contributors send in reviews (I find the coding style rather hard to get >> acustomed to as well, personally) or when fixing them by hand when >> seeing them (To make things worse, this often happens in a single commit >> together with functional changes which makes it really hard to see the >> relevant bits). >> All in all it feels like the code base is in a very inconsistent state. >> According to the developer documentation you should use uncrustify with >> the provided config to make sure the your code doesn't violate the code >> style, but it seems nobody really does that since running it on the code >> base yields a big diff stat. >> I would like to propose using clang-format to enforce a consistent code >> style and tried to put together a config which resembles the current >> style as close as possible. There are a few things that can't be >> achieved the way it's currently defined by the style guide. So I want to >> ask whether you guys are willing to make some compromises in that >> regard? Considering the benefits of not having to deal with code >> formattings etc. and the time it saves I think it's well worth it. >> Additionally the use of clang-format will allow the usage of all the >> great clang tools for further tool-based code cleanups/improvements while >> maintaining the defined code style >> >> Opinions? >> >> Best regards, >> Marvin >> > > I generally don't like the idea of using a code style formatting tool on > every commit. We have quite a few style items that are not defined > which means they are left to the preference of the developer such as > aligning variable names and multiple line function parameter > indentation. Forcing these few minor style issues just ends up making > devs frustrated. I'm not outright rejecting the idea. If I thought I > could get all of the KiCad devs to agree on all of the undefined coding > style items, I would have done this a long time ago. If you've ever > tried to get a group of devs to agree on a coding style, you'll > understand why I'm reluctant to open that can of worms again. I'm happy > with what we have currently so my motivation is low to go through that > again. :) > > Cheers, > > Wayne > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
