On 2015-07-14 6:53 PM, Birunthan Mohanathas wrote:
On 14 July 2015 at 08:23, Benjamin Smedberg <benja...@smedbergs.us> wrote:
The argument I am most sympathetic to is that this convention is a barrier
to new contributors. Making new contributors productive, both employees and
volunteers, is a very good reason to choose one style over another.
The C++ world is a huge mishmash of different styles. I don't think
Google style is necessarily any better than our style. And, to be
fair, our style is actually fairly close to Google style with a few
exceptions like variable naming.
I think the Google C++ style is definitely more closely maintained than
ours, but given that they both follow the same set of goals (make
dealing with large C++ code bases sane) the fact that we are similar
should not be a surprise.
The real issue is that we have vastly different code styles throughout
our codebase. We use 2 spaces for indentation in some modules and 4
spaces in others. Some places defiantly use tabs and a few files have
compromised on 3 space indentation (eww!). Some modules place the
pointer adjacent to the type, others put it beside the name. Some
modules always brace control statements, others do not.
That is mostly a cultural problem. I can't count the number of times
that I have seen people consciously not following the coding style.
That is not a problem that you can fix with switching coding styles,
since that would merely change the set of people who don't like the style.
It's not our style that is the problem for new (and old!)
contributors; it's the huge inconsistency. I'm making Clang-Format
compatible with our style over in bug 961541. Once Clang-Format is
good enough, I will rewrite the entire tree on a
directory-by-directory basis.
Yes, please!
FWIW, if you hit prohibitively complex issue that you couldn't solve in
clang-format, I think we may want to consider changing our coding style
to be enforceable through clang-format.
Once we have this set up, we can force people to conform. ;-)
Given that premise, we shouldn't just change aArgument; we should adopt the
Google C++ style guide wholesale:
* names_with_underscores
* members_with_trailing_
If we were to do this, some names would become shorter and other
longer. That might break the 80 column limit in places and break
alignment in others. (Also keep in mind that Google style mandates
`foo_bar()` for getters and `set_foo_bar()` for setters.) This is a
general problem with rewriting. In order to perform them effectively,
we need to have a consistent style and tool to automatically reformat
diffs to that style.
I personally don't think switching to Google style naming is worth it.
It would require far more changes than just sticking with either
aFooBar or fooBar for no apparent benefit.
FWIW, given the fact that we are far far away from having the magical
rewriting tools that can take a code base the size of ours and switch it
from Mozilla style to Google style, and do so correctly, I don't think
there is a lot of value to be gained from nitpicking the Google style.
We can save that conversation for when the magical tools exist. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
