E
Eberhard Schefold
Lionel said:
Good point.
Good point.
S
Stefan Ram
Eberhard Schefold said:
That's why a sentence is a better name for a predicate than »a«.
if( server_is_up() )...
Now, this is more natural-language like than
if( server_is_up() == true )...
E
Eberhard Schefold
Stefan said:
Generally I certainly agree with Lionel and you. But it's not always
that easy. Sometimes you don't have control over the naming, and even if
you have, often the return value only indicates success or failure of a
larger procedure with lots of side effects, say,
if( GenerateRevenueReports() )
...
I wouldn't want to change that name into something more "boolean", say,
if( GenerateRevenueReportsWasSuccessful() )
...
It's not clear now if the function actually performs the action or only
queries for its status. So, even with all the arguments, I still
understand why some people might find
if( GenerateRevenueReports() == true )
...
clearer to understand.
N
Nick Keighley
well in that case the function is badly named and has
an odd return type
I'd be tempted to hide the truth
const bool success = true;
if (GenerateRevenueReports() == success)
I've done this with APIs that use boolean parameters.
const bool erase_background = true;
InvalidateRect (hwnd, 0, erase_background);
E
Erik Wikström
But then again, sloppy programming has never been a good way to get
correct code. If a function returns something else than a bool you
should compare it to the expected result and not rely on the implicit
conversion (which should never have been allowed into the language).
K
kwikius
Erik Wikström said:
The reason for much of the strangeness of fundamental types semantics in C++
is inherited AFAICS from BCPL, one of the main precursors to C.
BCPL didnt differentiate ints and pointers. I think that "heritage" can be
traced back nearly 40 years ago now!
There was I believe a fair amount of argument about changing the semantics
when C was standardised, but not much could be done for the standard "legacy
code" reasons.
regards
Andy Little
regards
Andy Little
E
Eberhard Schefold
Pete said:
But why would anyone compare a non-bool return value with a bool
literal? Do you think this is a common idiom -- or a frequent mistake?
B
Bo Persson
Eberhard said:
Why would anyone compare a bool return value with a bool literal?
Bo Persson
E
Erik Wikström
I'm arguing against relying on explicit conversion to bool, if the
function returns non-zero on success you compare against non-zero:
if (0 != foo())
K
Krice
I'm using ==true always. I never got used in "if (x)" style, it's
confusing. But you earthlings don't always act in logical way.
J
James Kanze
It doesn't say anything more than just:
if ( GenerateRevenueReports() ) ...
I think it was Herb Sutter who first brought up the issue, but
there's already a serious problem if a function named
GenerateRevenueReports() returns a bool to indicate success: is
it true, the function succeeded, or true, there was an error?
The correct way to handle this is with an enum:
enum Result { success, failure } ;
Result GenerateRevenueReports() ;
In which case, of course, you write:
if ( GenerateRevenueReports() == success )
...
My general rule is that function names are verbs or verbal
clauses, and that predicate functions always use a form of the
verb to be or to have, e.g.: isRunning(), hasNoProblems(). Any
other function will use an enum (or some other user defined
type---I rather like a user defined type which asserts in its
destructor if it hasn't been tested) to report success or
failure.
There are exceptions, of course. The iostream idiom is too
ubiquious to be ignored, for example (and you can't change the
standard library even where it is completely irrational). And
there are cases where it makes sense to treat an extended type
as a bool, or verbs other than to be or to have which logically
respond with a bool (e.g. RegularExpression::matches()).
L
Lionel B
Ah, maybe your Martian grammar uses ternary logic as standard:
if (need_user_input == true)
\\ do something
else if (need_user_input == false)
\\ do something else
else if (need_user_input == um____not_sure_really)
\\ drink coffee
S
Stefan Ram
James Kanze said:
»Procedure names should reflect what they do;
function names should reflect what they return.«
Notes on Programming in C; Rob Pike; February 21, 1989
http://www.lysator.liu.se/c/pikestyle.html
This reflects the natural-language distinction between verbal
phrases and noun phrases. For example, the name »sin« of the
header »cmath« perfectly reflects what it returns. »sin( 0.0 )«
coresponds to the natural-language noun phrase »the sine of zero«.
I can not imagine how replacing »sin« 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() )...
S
Stefan Ram
Now I remember one boolean expression that was really harder
to read than other boolean expressions.
In a Java program (off topic here, but just to show how sane
C++ is in comparison), I once came across:
if (a != a)
It took me several seconds to remember how this might be true
in Java (Hint: it has nothing to do with the array access, the
same effect can be seen with »if( a != a )«.)
If the reader knows Java, but also does not understand this
expression immediately, this would prove that it is hard to read.
(Another hint: The type of the operands of »!=« is »double«.)
J
Jerry Coffin
[ ... ]
Actually, the same can occur in C++. TR1 provides a more direct method
though: if (isnan(a). Unless something changes, C++ 0x will have this
as well.
Actually, the same can occur in C++. TR1 provides a more direct method
though: if (isnan(a). Unless something changes, C++ 0x will have this
as well.
J
James Kanze
This is the same article that says "include files should never
include include files", right?
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 ownership).