On Sun, Sep 22, 2013 at 4:00 AM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > On Fri, 2013-09-20 at 09:41 -0500, Jo?o Paulo Rechi Vita wrote: >> On Thu, Sep 19, 2013 at 4:53 PM, David Henningsson >> <david.henningsson at canonical.com> wrote: >> > On 09/19/2013 01:17 PM, Damir Jeli? wrote: >> >> Sorry if I'm a little bit annoying here but I'd like to keep our from >> >> now on with as little style inconsistency as possible. I haven't done >> >> any proper review/testing on this, just a quick coding style check. >> > >> > Sorry if I'm even more annoying here ;-) but perhaps you haven't heard >> > my personal view on this matter. >> > >> > I totally disagree. I would instead like to keep our coding style rules >> > to a bare minimum to keep the code decently readable. Anything else is >> > just an additional road block towards what's important: spending as much >> > time as possible fixing bugs and implementing new features, rather than >> > spending time complying to coding style rules. >> > >> > So; for the opening bracket on newline - I think our current coding >> > style is wrong and should be changed for functions, and I always forget >> > that we have this odd style here. You're okay to comment on that, >> > because it is in our coding style rules, but I would appreciate more, as >> > you say, "any proper review/testing", rather than a simple coding style >> > check. You focus on what looks good on the surface, but what really >> > matters is real code quality - i e, whether the code is going to solve >> > our users' problems without causing annoying bugs, or not. >> > >> >> If you're really lazy you can use my sed script to fix this issues (well >> >> the opening bracket on newline issues at least).[2] >> > >> > For the stuff that's *not* in the coding style wiki page, I'm even >> > lazier. If you prefer a different style than I happen to write, feel >> > free to run your scripts every six months or so and submit a patch for >> > it, and I won't complain if somebody else reviews and commit it. (Well, >> > unless it severely decreases readability somehow.) >> > >> >> The problem with commits that only fix coding style is that it screws >> up history, making things like 'git blame' much harder, so I think we >> should avoid that as much as possible. The only way to avoid it is >> trying to have clear coding style rules and trying to adhere to them >> as much as possible. OTOH, I agree with David that there are some more >> important stuff for time to be spent on than spending time dealing >> with coding style. >> >> The only solution I know that would help is to have some coding style >> checker that would help us on finding problems with the coding style. >> This tool should be available in the repository, so anyone sending >> patches can check style before submitting patches, but this should >> also be checked by the maintainer before committing the code upstream. >> If any coding style problem is found at this later point, it's ok IMO >> that the maintainer fixes the coding style problems by himself >> (amending to the original commit) so we don't add an additional >> peer-review roundtrip. >> >> What do you guys think? > > A style checker script would be great. On another topic: I want a > pony ;) > Both things can be worked out. I'm not the one complaining that it is too hard to adhere to or to review coding style. > It seems that at least a mass conversion the current code base to the > new style is getting quite a lot of opposition, so that's probably not > going to happen. Then there's the question that should we keep > complaining about style violations with the curly braces. Should > contributors be allowed to put the curly braces where they want, and > inconsistencies would be fixed later if the lines in question are > modified as part of some other patch? The curly brace issue is such that > inconsistency wouldn't bother me much. > As said before, I think we should avoid coding style fixes as much as possible, and the only way to do that is stick to our coding style as much as possible in new patches. For the points that are already inconsistent IMO the should be fixed when the inconsistent lines are changed as part of a patch that actually does something. -- Jo?o Paulo Rechi Vita http://about.me/jprvita
