using ! or == false? your preference?

[Mark Wilden]

Because in this *one* case, it's dangerous to put the variable first
and the value second. In non-boolean cases, the compiler will throw an
error at you.

Actually, I was just commenting on why we C# programmers would care about an
ancient C compiler.

Note that although many of us treat all warnings as errors and would
spot any warnings, not everyone does - if a warning for
"if (x = false)" goes unnoticed, that could be pretty serious.

I do treat warnings as errors, myself, and I also write unit tests.

Of course, as I've already posted, I prefer if (!x) in the first
place...

Me too.

///ark

 

[Bob Jones]

I prefer to name things so that using the " ! " it reads well; and it's
is more concise. Often I'll put a space after the " ! " because, as
mentioned already, it's kinda easy to miss. Beyond that programmers
will just have to learn how to program well. Any programming idiom is
mauled by the inexperienced and incompetent.

And piggy-backing on the "if then" discussions, I've come to love the
tertiary statement. You know:
<some statement that resolves to a boolean> ? <execute if true> :
<execute if false>;
Very concise, readable, and much less typo-error prone.

 

[Dave Sexton]

Hi David,

I don't think "== true" is redundant for that reason, though. You could read
the "== false" as, "if it's false that x is true" as well.

It's redundant simply because the code will compile with just the predicate
itself, so there is no need for "== true" to be present.

 

[Dave Sexton]

Hi Anders,

Interesting thread.

Personally, I just use ! everywhere because I think it's quite easy to
understand, it only takes one key press, it's not going to accidentally assign
a value, and contrary to what other respondents have written, I don't think
that it's hard to miss at all. As a matter of fact, I never place a space
between the ! and the predicate in real code either, and I don't remember ever
exclaiming, "My code wasn't working as I expected, but then I realized that I
didn't see the !"

"false ==" and "== false" just looks sloppy to me for some reason, the latter
may be subject to accidental assignment with only a compiler warning and it's
more to type. Although, I agree that reading "== false" as, "if condition is
false" might make more sense than reading it as, "if not true", but that's not
the deciding factor for me. "false ==" is not readable at all, but is
recommended to prevent accidental assignment in certain situations.
Therefore, it makes sense to use ! in certain situations and then, for the
sake of consistency, all situations. The value of consistency here may be
arguable though.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

While in-between sessions at the Tech-ED in Barcelona, I overheard a
discussion between some developers. The subject of the discussion was code
layout (i.e. how each developer formats and writes code). What are your
takes at the following two examples? Which one would you choose and why?

// may be easier to read for short statements
if (boolean == false) {}
if (DetermineResultFromMethod(arg1, arg2) == false)) {}

or

// easier for longer statements?
if (! boolean) {}
if (! DetermineResultFromMethod(arg1, arg2)) {}

Thinking about it, we've had this discussion at the office several times,
and I've never seen any public discussion on the subject.

I am all for the use of the ! operator.

The reason is that ==false and ==true gives me associations about
very inexperienced programmers.

Arne

 

[Kevien Lee]

what the code is shorter,the coder is smarter

 

[Guest]

This is same reason I prefer the ! syntax to "== false" Whenever I create a
property or function that returns a bool I try to give it a name that can
easily be read like a sentence, whenever I see ! that immediately translates
to NOT in my mind so something like:

if(!MaxValue) // if not MaxValue
{
}

seems a lot clearer than:

if(MaxValue == false)
{
}

which takes a few more cycles of my brain to evaluate than the first way.

Mark.

 

[JR]

I would have named it ValueAtMax, I thing it is clearer. MaxValue would be
more appropriate to the maximal value.

I find that I make much use of PF2 to rename things so that the names are
clear and uncofusable.

JR

 

[Ebbe Kristensen]

Why write code in C# as if you were writing code for an ancient C
compiler?

I picked this trick up many years ago when I used an ancient C compiler

Ebbe

 

[Dan Bass]

So... all in all, seems I was outnumbered 10-1!
Go for the "!"

 

[Dave Sexton]

Hi Jon,

You were referring to a developer only typing a single = character on
accident, correct?

if (variable == constant)

[...] with no fear of accidental assignment.

I think you mean

if (constant == variable)

can be used with no fear of accidental assignment.

The compiler allows the code I posted previously

bool aBool = false;
if (aBool = false) { }

although it does display a warning.

 

[Jon Skeet [C# MVP]]

You were referring to a developer only typing a single = character on
accident, correct?

if (variable == constant)

[...] with no fear of accidental assignment.

I think you mean

if (constant == variable)

can be used with no fear of accidental assignment.

No, I meant exactly what I wrote. See the previous paragraph:

<quote>
unless you actually *do*
comparisons of boolean values using == (which you very rarely need to
do anyway) you can write comparisons in the more readable
</quote>

In other words, for types other than boolean, the compiler stops you
anyway, and for boolean comparisons you can usually just do:

if (foo)
or
if (!foo)

 

[Bill Butler]

This is same reason I prefer the ! syntax to "== false" Whenever I
create a
property or function that returns a bool I try to give it a name that
can
easily be read like a sentence, whenever I see ! that immediately
translates
to NOT in my mind so something like:

if(!MaxValue) // if not MaxValue
{
}

seems a lot clearer than:

if(MaxValue == false)
{
}

which takes a few more cycles of my brain to evaluate than the first
way.

I agree completely

if (!Done) --> If not Done

Unfortunately I have maintained code from programmers who aren't as
careful with there naming.

example:

if (!NotDone) --> if not 'Not done'

Ugh, double negatives hurt my brain.

Of course in this case I generally rewrite the logic to be less painful.

Bill

 

[tjmadden1128]

Make it 11-1!
I consider it a standard practice. I've had one or two languages where
the ! operator was not defined, and I always thought it was odd.

 

[Guest]

Yea, MaxValue was not a very good example in this case.

 

[Bobbo]

And piggy-backing on the "if then" discussions, I've come to love the
tertiary statement. You know:
<some statement that resolves to a boolean> ? <execute if true> :
<execute if false>;
Very concise, readable, and much less typo-error prone.

That's one of my current favourites too, although when I first started
using it in Javascript (yes, OT again sorry) I forgot the syntax and
couldn't remember what it was called either - try searching for that in
Google!

 

[Anders Borum]

Hi Mattias,

Yea, the good ol' discussion on tertiary statements just ressurected!

And piggy-backing on the "if then" discussions, I've come to love the
tertiary statement. You know:
<some statement that resolves to a boolean> ? <execute if true> : <execute
if false>;
Very concise, readable, and much less typo-error prone.

I'm also a big fan of that and it's extremely fast to write (and read, once
you spend a few days with it).

 

[Anders Borum]

Hello!

The reason is that ==false and ==true gives me associations about
very inexperienced programmers.

Although I prefer the ! operator, I wouldn't necessarily agree with the
above statements.

Lots of people acknowledged it was up to personal preference (although good
arguments has been presented - especially on accidental assignments). I
would base my rating of a developer on overall code efficiency, architecture
and quality (documentation too) than the - perhaps intentional - use of the
== false pattern.

 

[Dave Sexton]

Hi Jon,

Thanks for clearing that up for me.

--
Dave Sexton

You were referring to a developer only typing a single = character on
accident, correct?

if (variable == constant)

[...] with no fear of accidental assignment.

I think you mean

if (constant == variable)

can be used with no fear of accidental assignment.

No, I meant exactly what I wrote. See the previous paragraph:

<quote>
unless you actually *do*
comparisons of boolean values using == (which you very rarely need to
do anyway) you can write comparisons in the more readable
</quote>

In other words, for types other than boolean, the compiler stops you
anyway, and for boolean comparisons you can usually just do:

if (foo)
or
if (!foo)

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Although I prefer the ! operator, I wouldn't necessarily agree with the
above statements.

You won't agree that I get that association ??

Lots of people acknowledged it was up to personal preference (although good
arguments has been presented - especially on accidental assignments). I
would base my rating of a developer on overall code efficiency, architecture
and quality (documentation too) than the - perhaps intentional - use of the
== false pattern.

Where I come from we do not base rating on associations at all - not
from coding style or code efficiency or anything else.

But that does not prevent me from getting associations.

And it does not prevent me from wondering what people
think when they read my code.

Arne