unused parameters

[Thiago Farina]

Hi,

Is it recommended to comment out unused parameters? I think that is
pretty uncommon in Chromium code (I don't remember doing that myself
though), but that came in a review and is suggested by the style guide
[1].

For me, that just adds noise for little gain. Maybe I'm missing
something clearly.

[1] - http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Declarations_and_Definitions#Function_Declarations_and_Definitions

--
Thiago

[Brett Wilson]

Comment it out if you get a compiler warning. I believe most of our
code has that warning disabled, in which case I'd just leave it
uncommented.

Brett

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Steve VanDeBogart]

There are parts of the code base that follow this rule (even when the compiler wouldn't complain). For consistency's sake, can we please follow the rule unless there is a local practice in the file or directory which doesn't?

--

Steve

[David Michael]

On Mon, Sep 23, 2013 at 9:15 AM, Steve VanDeBogart <van...@chromium.org> wrote:

There are parts of the code base that follow this rule (even when the compiler wouldn't complain). For consistency's sake, can we please follow the rule unless there is a local practice in the file or directory which doesn't?

+1. We should try to follow Google style where it makes sense, and I find it a good hint to the reader that the variable is unused.

[Peter Kasting]

On Mon, Sep 23, 2013 at 8:15 AM, Steve VanDeBogart <van...@chromium.org> wrote:

There are parts of the code base that follow this rule (even when the compiler wouldn't complain). For consistency's sake, can we please follow the rule unless there is a local practice in the file or directory which doesn't?

Nearly all Chrome code does not comment out unused param names.  If you want to talk about project-wide consistency, Brett's comment is the consistent position.

Within files that _do_ comment out names, I have no problem with people being locally consistent across the file.

The backstory here is that the original Google style rule was intended to be in contrast to not providing param names at all, e.g. "void foo(int)".  Since unused param names classically generated a warning on the compilers Google used, the choice was no name or a commented-out name, and the style rule was written to ban the former.

When we began doing work in Windows, where MSVC typically doesn't warn about this, we checked with the style arbiters and the opinion we received was that using uncommented param names was fine, as it still accomplished the original goal ("document what each arg actually is").  It's actually better IMO than commenting out the name, because it reduces visual noise.

PK

[Steve VanDeBogart]

*sigh*  I know we don't want to increase the size of the Chromium style guide, but having every developer learn the exceptions to the style guides that aren't written down doesn't scale either.  Any objection to writing down this explicit contradiction in the Chromium style guide?

--

Steve

[Peter Kasting]

On Mon, Sep 23, 2013 at 12:09 PM, Steve VanDeBogart <van...@chromium.org> wrote:

*sigh*  I know we don't want to increase the size of the Chromium style guide, but having every developer learn the exceptions to the style guides that aren't written down doesn't scale either.  Any objection to writing down this explicit contradiction in the Chromium style guide?

I don't think we should notate this.  FWIW, the Google style guide was slightly rewritten to try and emphasize that the problem is completely-unnamed parameters.  It's still not as clear as I'd like, but the style guide rarely is :P

Truly, I have never seen this be a problem in past codereviews.  Almost no one knows about the original style rule, people who do can legally go ahead and comment out variable names, so it doesn't seem like a big deal.  "Be consistent with the code around you" covers this well enough IMO.

PK