On 7/7/2015 15:03, Kartikaya Gupta wrote:
I'd be interested to know: of those people who are in favour of
removing the prefix, how many regularly have to deal with functions
that are longer than two pages (a "page" is however much code you can
see at a time in your coding environment)?
All the time?
I'd be happy to support
removing the prefix if people also commit to splitting any giant
functions they touch as part of the prefix removal.
That's (sorry) non-sense. In almost all cases longer methods/functions
cannot be just split. It would probably make the code just much harder
to read and maintain (with a lot of new arguments missing the 'a' prefix
;)) and is not necessary. Not an argument IMHO.
-hb-
Also FWIW in the current world I do find the prefix useful when
debugging in gdb, because I know I can keep going up a frame as long
as I'm tracing a variable with the prefix, whereas otherwise I would
have to step backwards through each frame to see where the variable is
coming from. I'll probably find some way to adapt if we remove the
prefix though.
kats
On Tue, Jul 7, 2015 at 7:54 AM, Honza Bambas <hbam...@mozilla.com> wrote:
I'm strongly against removing the prefix. I got used to this and it has its
meaning all the time I inspect code (even my own) and doing reviews.
Recognizing a variable is an argument is very very useful. It's important
to have it and it's good we enforce it!
-hb-
On 7/7/2015 5:12, Jeff Gilbert wrote:
I propose that we stop recommending the universal use of an 'a' prefix for
arguments to functions in C and C++. If the prefix helps with
disambiguation, that's fine. However, use of this prefix should not be
prescribed in general.
`aFoo` does not provide any additional safety that I know of.[1] As a
superfluous prefix, it adds visual noise, reducing immediate readability
of
all function declarations and subsequent usage of the variables within the
function definition.
Notable works or style guides [2] which do not recommend `aFoo`: [3]
* Google
* Linux Kernel
* Bjarne Stroustrup
* GCC
* LLVM
* Java Style (Java, non-C)
* PEP 0008 (Python, non-C)
* FreeBSD
* Unreal Engine
* Unity3D (largely C#)
* Spidermonkey
* Daala
* RR
* Rust
* Folly (from Facebook)
* C++ STL entrypoints
* IDL for web specs on W3C and WhatWG
* etc.
Notable works or style guides which *do* recommend `aFoo`:
* Mozilla (except for IDL, Java, and Python)
* ?
3rd-party projects in our tree which do not use `aFoo`:
* Cairo
* Skia
* ANGLE
* HarfBuzz
* ICU
* Chromium IPC
* everything under modules/ that isn't an nsFoo.c/cpp/h
* etc.?
3rd-party projects in our tree which *do* recommend `aFoo`:
* ?
As far as I can tell, the entire industry disagrees with us (as well as a
number of our own projects), which means we should have a good reason or
two for making our choice. No such reason is detailed in the style guide.
I propose we strike the `aFoo` recommendation from the Mozilla style
guide.
-
[1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed
by spec, or at least MSVC 2013 errors when compiling this.
[2]: I do not mean this as an endorsement of the listed works and guides,
but rather as illustration on how unusual our choice is.
[3]: I created an Etherpad into which people are welcome to gather other
works, projects, or style guides that I missed:
https://etherpad.mozilla.org/6FcHs9mJYQ
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
