On May 7, 5:16 pm, r...@[EMAIL PROTECTED]
(Stefan Ram) wrote:
> James Kanze <james.ka...@[EMAIL PROTECTED]
> writes:
> >My general rule is that function names are verbs or verbal
> =BBProcedure names should reflect what they do;
> function names should reflect what they return.=AB
> Notes on Programming in C; Rob Pike; February 21, 1989
> http://www.lysator.liu.se/c/pikestyle.html
This is the same article that says "include files should never
include include files", right?
> This reflects the natural-language distinction between verbal
> phrases and noun phrases. For example, the name =BBsin=AB of the
> header =BBcmath=AB perfectly reflects what it returns. =BBsin( 0.0
)=AB
> coresponds to the natural-language noun phrase =BBthe sine of zero=AB.
> I can not imagine how replacing =BBsin=AB it by a verb or
> verbal phrase would improve things.
> The only problem are mixed operations (functions) that both do
> something and return a result.
> if( fopen( "alpha", "r" ))...
> Such beasts do not occur in natural-language use. So no
> model for them can be derived from natural-language use.
> A possible solution using an abstract-datatyp object
> would be to separate the two. For example as follows:
> File f;
> f.open( "alpha", "r" );
> if( f.is_ready_for_use() )...
Seriously, you have a point, and the issue with regards to
functions is a little more complex:
First, if the "function" does something, it's not a function;
it's a procedure with an out parameter. The name should be a
verb or a verbal phrase.
Second, math functions are a special case: sin isn't a normal
English word, and it means exactly that: the function in
question. Any other name (e.g. std::sin, or Math.sin) just
doesn't cut it.
For the rest, I tend to distinguish: if the function returns a
pure value, or a reference to some object which is conceptually
part of the object it is called on, I use the name of the value
or the object---generally a noun. If the returned value is an
object, but is not conceptually part of the object it is called
on, then I use a verb phrase: "Whatever::widget()" returns a
reference to the widget which is conceptually part of Whatever,
but "Whatever::getWidget()" or "Whatever::findWidget()" will
return a widget, or a reference to a widget, that may exist
elsewhere, which presumably, Whatever has to do some work to
find, and "Whatever::createWidget()" returns some new object
(usually with transfer of owner****p).
--
James Kanze (GABI Software) email:james.kanze@[EMAIL PROTECTED]
en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
|
