On 1/7/2014 1:16 PM, Martin Thomson wrote:
Hungarian notation = unnecessary and costly (technology fixed this problem
years ago, for member vs. local most editors can do syntax highlighting; plus,
it’s easier to type and read without it).
Especially for new contributors we shouldn't assume that most editors
can do this correctly. I personally think that the risk of introducing a
new member and then having locals shadow members is real enough that we
should somehow distinguish them. I don't have strong opinions about our
current mFoo naming versus the google-like member_ naming.
Braces always = net win. Consistency + bug resilience > any aesthetic
preference (which is trained anyway).
It's not really a question of aesthetic preference. It's a question of
reducing the vertical size of a method so that more of it fits on
screen, especially when dealing with small error-handling paths. But
we've had this conversation twice before, and Brendan decided that the
always-braced style was the one we were going to use. So, despite it
being not my personal preference, it's already settled and not worth
reopening ;-)
Here’s a few other things that I think should be added:
function and file length limits:
I think that 32 lines is enough for JS, and maybe 50 for C/C++ due to the
increased need for error checking stuff.
1000 lines is enough for any single class/file.
I’m certain others will want much longer :) Why so short? Function names are
great just-in-time help, and long functions suffer from tl;cr (too long; can’t
read).
cyclomatic complexity limits:
I like 8 for JS and probably 15 for C/C++ due to the impact of error checking.
Again, I’m sure others will want more.
The style guide is *mostly* a place to describe existing practice and
formatting conventions. Your proposal here isn't in scope for the
current discussion, nor something that at all describes current practice.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
