lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [lmi] omitting parameter name


From: Vadim Zeitlin
Subject: Re[2]: [lmi] omitting parameter name
Date: Fri, 13 Apr 2007 22:33:00 +0200

On Fri, 13 Apr 2007 16:03:49 +0000 Greg Chicares <address@hidden> wrote:

GC> > class printable
GC> > {
GC> >  void print_me(std::ostream&) const;
GC> > };
GC> 
GC> I think naming the parameter would make that declaration less good.
GC> What could we name it? Its meaning is just "that ostream we're using".
GC> Its type is its entire meaning. Giving it a name would make the
GC> declaration longer, but not clearer.

 Of course in most cases you can understand what parameters mean even
without naming them -- this is what almost defines the good design at
functional level. But I don't think it's right to say that if you can
omit something, then you should. Making what is already there implicitly
explicit can still be helpful.

GC> Yes, I think it's good to give the obvious parameter no name,
GC> and to give the non-obvious parameter a meaningful name. These
GC> alternatives would be less good IMO:
GC> 
GC>   void print_me(std::ostream& os, bool include_title) const;
GC>                              ^^^ not helpful
GC> 
GC> To parse that mentally, I have to waste time reading 'os',
GC> recognizing that it is only a meaningless placeholder, and then
GC> disregarding it.

 It must be a question of habit for me (although I suspect it's a very
widespread habit) but for me reading the declaration without some parameter
names is really difficult. The proof is that I pause at it when reviewing
all patches to LMI code. I'm just too used to seeing parameters in pairs
"type name" and while I can adapt to not having any parameter names at all
(although I very rarely, if ever, omit them) reading a type, then a type
with a name, then another lone type is very disconcerting IMHO.

GC> That might not save much mental parsing effort, but the cumulative
GC> savings across many declarations can make it significantly easier
GC> to see an entire class declaration's meaning at a glance.

 I don't think you can make significant savings on names. Types are much
longer usually.

GC>   void print_me(std::ostream&, bool) const;
GC>                                ^^^^ unknown meaning

 Well, this is just because boolean parameters used with functions taking
more than one easy to understand "on/off" parameter are evil anyhow as I
tried to explain at

        http://www.wxwidgets.org/develop/standard.htm#no_bool_params

So I don't believe naming this parameter would do any good, the function
signature has to be changed anyhow. So ideally all parameter names should
be self explanatory just because of their types. Does it mean that we
should always omit names for all parameters? I feel that this would be the
[only] logical conclusion of your approach. However not having parameter
names at all is IMO a bad idea. It makes it impossible to refer to them in
comments (whether using Doxygen or a similar tool or in free-form comments)
and I still believe that reading is facilitated by the parameter names, not
hampered by them.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]