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? -- Jo?o Paulo Rechi Vita http://about.me/jprvita
