using ! or == false? your preference?

[Anders Borum]

Hello!

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.

 

[Dan Bass]

Personal preference, I always go for "== false" if for one reason only... My
eye sometimes misses a single "!"

 

[=?ISO-8859-15?Q?Martin_P=F6pping?=]

Personal preference, I always go for "== false" if for one reason only... My
eye sometimes misses a single "!"

So I have the other personal preference.

I prefer a shorter code if the code is not more difficult to understand.

and a "!" instead of a "== false" is much shorter but not more difficult
to understand (assumed that you do not have a poor eyesight or poor glasses)


Regards,

Martin

 

[Guest]

definatley the first one. it's much easier to read.

 

[Tom Porterfield]

Hello!

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.

It just comes down to personal preference and which you find easier to read.
I personally use the latter but can read either one just fine. Those
unfamiliar with C# will find the first easier to understand, but when seeing
it they will have no motivation to learn anything more about C#.

My opinion is it's generally best not to dictate things that come down to
personal style choices when it is as simplistic as your example. There is
no strong justifiable reason to force anyone to use one syntax over the
other.

 

[Dave Sexton]

Hi Anders,

Using the ! character is safer in case you accidentally forget an = character:

bool aBool = false;

if (aBool = false)
{
// aBool was false, but this code won't execute
// Worse even, the compiler allows it
}

Although, the compiler does give a nice warning

 

[Dan Bass]

Ah you could aruge that if you miss an extra "=", you could potentially miss
! from (!MyVar).
That would give you no warning. ;-)

 

[Ebbe Kristensen]

Using the ! character is safer in case you accidentally forget an =
character:
bool aBool = false;

if (aBool = false)
{
// aBool was false, but this code won't execute
// Worse even, the compiler allows it
}

Although, the compiler does give a nice warning

Always put the constant first:

if( false = aBool )
{
}

won't compile, not even with the most ancient C-compiler, you can come up
with.

Ebbe

 

[Bobbo]

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).

Slightly OT, but we had a similar discussion in the days of ye-olde
ASP, on which of the following was more efficient.

This one:
If <condition> Then
var = 1
Else
var = 2
End If

Or this one:
var = 2
If <condition> Then var = 1

Imagine how heated that got when I threw IIF() into the pot, for fun.
By the way, the outcome was much the same as this one.

 

[Dave Sexton]

Hi Dan,

No, they're really not the same.

I've accidentally entered a single = at times but I've never just forgotten to
type "!" when I was trying to negate an expression.

I'm speaking more of a type-o.

 

[Dave Sexton]

Hi Ebbe,

Good point. Now, it's looking a lot closer to:

if (! aBool)
{
}

 

[Dan Bass]

Agree with the OT bit! Using == false or ! or your example below doesn't
dictate good or bad programming practices...

If at the end of a month long discussion a conclusion was agreed upon that !
is the way to go, but everyone forgot to comment their code, or even worse,
comment their code badly, then the readability of the ! suddenly becomes a
non-event.

As long as the style is clear and consisten, easy to read and well designed,
then things like this are irrelevant.

 

[Mark Wilden]

Always put the constant first:

if( false = aBool )
{
}

won't compile, not even with the most ancient C-compiler, you can come up
with.

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

///ark

 

[Mattias Sjögren]

Anders,

Which one would you choose and why?

Why not

if (DetermineResultFromMethod(arg1, arg2) != true)) {}

<g>

No seriously I tend to use !



Mattias

 

[Jon Skeet [C# MVP]]

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.

If I'm treating the boolean as a *condition* (which is the usual case)
I'll use if (!condition)

That way when I read it it's: "if not condition" which makes more sense
to me than "if condition equals false".

If it's a "value" in itself (and I'm struggling to even think of any
examples here) then I'd probably be okay with if (value == false).

 

[Jon Skeet [C# MVP]]

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

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.

Now, it happens to *warn* you if you do

if (x = false)

but it wouldn't warn you with:

if (x = SomeMethodCall())

whereas

if (SomeMethodCall() = x)

will give an error.

I know it's not quite the same situation, but it's still interesting

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.

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

 

[Guest]

I think the risk with the "== false" approach is that you might be tempted to
start coding "== true" to be consistent and that would just be redundant
(then you'd read your boolean conditions as "if it's true that x is true"...).
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: VB to Python converter

 

[Anders Borum]

Mattias,

Good one. I needed that here at 9:30 pm ;-)

Also good to see the comments. I agree with the statements on variable
assignment being a bad thing, but also realize that this is one of those
things that may be left open for decision by the developer (where as
programming syntax etc. is a whole other discussion - we enforce that at our
company (all developers agreed on syntax, so it's not a problem)).

 

[Ben Voigt]

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

Because those who don't learn from history (even ancient history) are doomed
to repeat it.

 

[Jon Skeet [C# MVP]]

Because those who don't learn from history (even ancient history) are doomed
to repeat it.

Fortunately in this case, the C# language designers learned from the
mistakes of the C language designers - 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

if (variable == constant)

way with no fear of accidental assignment.