next »

[Kekskiller]

Try comparing a boolean to true or false in a job interview and you'll get laughed out of the room.  That is extremely bad form.  Not having to do that is the whole point behind a boolean data type.

If I saw someone had done that I'd most likely hire them (unless there was something wrong with the rest of their code). It may be less elegant than using the boolean value directly in the test, but at least it deviates from that in the direction of increased clarity. That's a good fault to have.

Seconded.

[Average Software]

Try comparing a boolean to true or false in a job interview and you'll get laughed out of the room.  That is extremely bad form.  Not having to do that is the whole point behind a boolean data type.

If I saw someone had done that I'd most likely hire them (unless there was something wrong with the rest of their code). It may be less elegant than using the boolean value directly in the test, but at least it deviates from that in the direction of increased clarity. That's a good fault to have.

Seconded.

Increased clarity?  It's no different than this:

Code:

if ((x == 5) == true)

or this:

Code:

if (obj1.operator == (obj2))

Sure, it works, but it demonstrates a profound misunderstanding of a language feature.  By the way, I've seen all of the above in production code.  Those people aren't working anymore.

[Kekskiller]

Increased clarity?  It's no different than this:

Code:

if ((x == 5) == true)

or this:

Code:

if (obj1.operator == (obj2))

Sure, it works, but it demonstrates a profound misunderstanding of a language feature.  By the way, I've seen all of the above in production code.  Those people aren't working anymore.

Don't start offending people by how they're doing their hobby projects. Also, code is flexible and your sentence makes me think that you're pretty fixed in terms of code. This said, you seem to be one of these guys who think that there's a specific way how to make good code in a specific language. Just think about - good code. That's paradox.

Such statements are not good for developers. Especially because there are aso many ways leading to Rome.

[Average Software]

Don't start offending people by how they're doing their hobby projects.

No offense was intended, and I don't where it's coming from.  I also saw no evidence that the code was from a hobby project, or any project whatsoever.

If this code is in fact from a hobby project, then this is exactly the sort of place to get this stuff right, not down the road when you're doing something important.

Also, code is flexible and your sentence makes me think that you're pretty fixed in terms of code. This said, you seem to be one of these guys who think that there's a specific way how to make good code in a specific language.

What I have a problem with are things that I call "provably stupid."  For example, we once had this ridiculous policy in place, created by someone who didn't know what they were doing:

Code:

// Always do this:
if (some_pointer != NULL) delete some_pointer;

Stuff like this is a huge red flag to anyone that actually knows a language, and the boolean comparison falls in the same category.  This is provably stupid, since deleting NULL is safe, and not only that, but NULL is the only value that is guaranteed to be safe to delete.  Therefore this statement has the precise opposite effect as its intent.  Fortunately, I was able to get the policy removed.

The boolean comparison is provably stupid since if (a == true) can be reduced to if (a).  It's not a question of opinion, it's a question of mathematics.

Note that this is different than using if (pointer) to test for a NULL pointer.  The pointer test is exploiting the C definition of true and false to avoid some typing.  This I (and many others) do not approve of.  Arguments against it include that fact that the variable "pointer" does not represent a truth value (where the boolean does), and it also assumes a NULL value of 0.  (I believe there are some obscure systems where the NULL pointer isn't 0)  Here once again, it's simple mathematics.  if (pointer != NULL) is correct 100% of the time.

I also dispute your claim of clarity, since my (and several of my co-workers) first reaction to code like if (a == true) is to start looking around for some wacky overloaded operators to find out what the hell is going on.  I think, "Why would someone do that?  What am I not seeing?"

Once again, no offense is (or was) intended.  I've just seen this sort of thing way too many times, and it's always shown itself to be a bad habit.

[Kekskiller]

I also dispute your claim of clarity, since my (and several of my co-workers) first reaction to code like if (a == true) is to start looking around for some wacky overloaded operators to find out what the hell is going on.  I think, "Why would someone do that?  What am I not seeing?"

Once again, no offense is (or was) intended.  I've just seen this sort of thing way too many times, and it's always shown itself to be a bad habit.

And that is your problem: You think there is a meanness, a non-standard code or whatever. You rely on your experience - that's not always good (as we can read in this thread!). But there isn't any code that could do bad things to you, because it's not your code and you don't have to work with it. We're are talking about thousands of different coding styles, thousands of implementation and you're discussing such a tiny bit that doesn't matter until it doesn't work like intended. The grumpy old programmer room is a place where we can rant together, not the other way. Atleast I felt offended (and your second post didn't made it better!). I'm unforgiving.

So let's shut up in order to spread harmonic vibes all over this place! Making grumpy programmers and grumpy code fetishists happy people!

And please, please, please stop discussing if code A or B is better than C - except it makes BOOM and you have to find a solution. Open a new thread for this shit.

[team_q]

I also dispute your claim of clarity, since my (and several of my co-workers) first reaction to code like if (a == true) is to start looking around for some wacky overloaded operators to find out what the hell is going on.  I think, "Why would someone do that?  What am I not seeing?"

Noob programmer thinking :
 
int   = number without decimal places
float = number with decimal places
bool  = true or false

Code:

if (inty == 1)
if (floaty == 1.3f)
if (booly == true)

and yes, I do write it as

Code:

if (booly)

I know there was no offense intended but saying a somewhat innocuous coding quirk is a career ending grievous error, its a little intimidating and off putting!

[Schtee]

Though I don't like prefixing variables with their type, as that automatically makes your code less flexible, isn't the full type a bit overkill? Wouldn't bY suffice? Or expressive code, isY?

EDIT: Not criticising, just asking why. Don't eat me!

[Cthulhu32]

Oh boy, this is getting into NULL pointer conversations! Quick note for Eric, this little bit of code:

Code:

if(booly=true) doStuff();

is setting booly to true in C/C++, and then checking if booly is true I think thats why Average Software is freaking out.

If you say

Code:

if ( myValue == true ){
 blah blah blah
}

it can actually clarify the code slightly because the reader of the code then understands that myValue should be a bool. If you just say

Code:

if ( myValue ){
 blah blah blah
}

This can mean myValue is any value greater than 0, so you do not know if its a boolean, a pointer, a char, a function pointer even..

Also, for null pointers, I think the guidelines might have meant this:

Code:

if ( ptr != NULL )
{
   ptr->doStuff();
   myValue = ptr->value;
   delete ptr;
}

that way you don't try to act on a null pointer. But if you manage the pointer elsewhere like in a deconstructor then you don't need to delete the pointer directly after using it, you can delete it later on in the program.

I will be a grumpy programmer for a second about program variable names though. Please never define something that is funny at the moment, that will eventually cause a major program crash later on. For example

#define DonkeyPeedOnMe(i) ( (i) >= 0 ? (i) : -(i) )

or

#define bakabakatotoro TRUE

It makes me rage  Also, I freaking hate multithreaded pointer variable access for large programs. I'm executing the exact same functions in two different threads, but because one thread created the original pointer, the other thread does not have sufficient access to use it. DuplicateHandle also does not work because of the way the pointer was originally setup.

[team_q]

Though I don't like prefixing variables with their type, as that automatically makes your code less flexible, isn't the full type a bit overkill? Wouldn't bY suffice? Or expressive code, isY?

EDIT: Not criticising, just asking why. Don't eat me!

Its my retched programming style to name variables that just hold values whatever variable type it is  + y.

So an int I can't think of a good name for is inty. This doesn't happen as often as when I just began.
Because I've been working a lot more with VS and C#. I've managed to start using more clear variable names.

If it is a position or velocity or something, I use Vectors. But that might be bad programming practice or something.

[Schtee]

I'll let it go then  

[William Laub]

If it is a position or velocity or something, I use Vectors. But that might be bad programming practice or something.

IMO that's the best use for vectors because that's usually what a vector is.

[team_q]

Oh boy, this is getting into NULL pointer conversations! Quick note for Eric, this little bit of code:

Code:

if(booly=true) doStuff();

is setting booly to true in C/C++, and then checking if booly is true I think thats why Average Software is freaking out.

That was what I was trying to show,
(I'm going to do it with ints)

Code:

if (1 = inty)//won't compile

if (inty = 1)//will compile, and you will get wackass run time bugs, and possibly not know why

Average software got on my case because I was comparing a boolean to true/false.

[Guillaume]

People should stop arguing about language semantics and get some code written already. 

[Average Software]

Also, for null pointers, I think the guidelines might have meant this:

Code:

if ( ptr != NULL )
{
   ptr->doStuff();
   myValue = ptr->value;
   delete ptr;
}

that way you don't try to act on a null pointer. But if you manage the pointer elsewhere like in a deconstructor then you don't need to delete the pointer directly after using it, you can delete it later on in the program.

That's perfectly reasonable, but no.  The guidelines were established by a former ignorant programming chief who somehow got a bug up his ass about deleting NULL pointers.  We even had a macro for it.

[Core Xii]

I (almost) always do:

Code:

if (boolean == true)
if (integer > 0)
if (string != '')

Because it promotes clarity and avoids confusion. In the end it generates just as fast compiled code as:

Code:

if (variable)

But it avoids mistakes, especially if you program across different languages with different rules for considering non-boolean values as true or false within expressions. (especially with strings!)

[Mr. Yes]

I think either one is good, though I prefer leaving out the "== true" because it tends to read better without it. For instance, "if (awesome)" sounds a lot better than "if (awesome == true)" to me.

[Lemming]

This is provably stupid, since deleting NULL is safe, and not only that, but NULL is the only value that is guaranteed to be safe to delete.  Therefore this statement has the precise opposite effect as its intent.  Fortunately, I was able to get the policy removed.

This is arguably done by someone who used common logic rather than knowing language features. The person is possibly aware that doing stuff with a NULL pointer tends to make shit crash.

During sometime in their app they conditionally allocate a variable: some_pointer = new some_type();

Using the logic they know, they have to delete whatever they've allocated. Since they could be unaware of whether this was actually allocated or not they use common logic: You cannot delete what doesn't exist. So they simply follow that logic, and checks for some_pointer's validity before removing it.

It's not provably stupid just because people are unaware of language features.

Arguably, as people apparently think, comparing a boolean value to true/false adds readability to your code. If you're used to see comparative operators within if-cases then if(booly) could make you go "huh?", whereas if(booly == true) follows the same pattern as if(x == 5), which is cozy and familiar for some.

I'd believe that compilers have come far enough to optimize this thing out (fact pulled out of my ass, no guaranteed validity), so it just boils down to a matter of code style. This I think that people are free to choose themselves. Although you can make them aware of "== true"'s obvious redundancy.

[Average Software]

Arguably, as people apparently think, comparing a boolean value to true/false adds readability to your code. If you're used to see comparative operators within if-cases then if(booly) could make you go "huh?", whereas if(booly == true) follows the same pattern as if(x == 5), which is cozy and familiar for some.

No, no, no.  The explicit == true or == false reduces the clarity of code, at least in C++.  This is why:

Code:

if (b)

What type is b?  I don't know.  All I know is that it's some type that's convertible to bool.  It could be any number of built in types, it could be any user-defined type for which operator bool() or some other boolean compatible conversion is defined.

Now:

Code:

if (b == true)

What type is b?  I don't know.  It could be any type that it convertible to bool, OR it could be any type for which operator == is defined for bool.  It could even be a type with both, in that case, which one takes precedence?  What actually happens here?

In both cases, the type of b and what the statement actually does cannot be determined from the statement alone.  In the longer case, there are even more possibilities for what the code is actually doing.  The shorter case eliminates all the operator == possibilities that can arise.

The only justifiable use for == true and == false are for types that are boolean comparable but not boolean convertible, in which case you would have to write it that way.

== true and == false gain you absolutely nothing and actually cost you something by making it more unclear as what the code could be doing.  This is practically the definition of a bad coding practice.

[Aquin]

That's a damn good point. 

[team_q]

But, but, but, I work in Visual Studio C#! Safety gear programming.

In the time you spent laughing at noob programmers or worrying if == has been recast in a new exciting role.

You could've done this:


But hey, if that kind of stuff gets me laughed at, sounds like a job for dicks anyways. I remember when programming was fun.

Edit: I guess to me it sounds like:
Guy 1 - "Man that dude sure was mad!"
Guy 2(computer engineer)"Mad as in crazy or Mad as in angry, I cannot parse your sentence because I don't want to to prove a point! If you don't strive for clarity I don't think we can be friends."
Guy 1 - "What? It's contextually appropriate, and you clearly understand!"
Guy 2 - "Also, you should comment your code better."