|
They were probable taught to program by some CS grad student who'd never done much significant real-world coding. That's right along the lines of the kinds of stupidity my teachers would teach us when I was an undergrad. Like everybody else, I picked up the stupidity too.. which lasted until I saw the other way and had to debug code to a schedule that was broken by such nonsense.
I still do the compare to NULL sometimes, but I believe the C standard now defines NULL pointers as a false boolean value, so it is redundant and I'm trying to retrain away from it. Besides, boost smart pointers, which we use a lot in our code, have an override to generate a bool result for just such kinds of pointer checks and make comparing the raw pointer to NULL harder.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Personally, I don't promote the C rule that implicitly turns an expression to boolean based on zeroness, whatever the type. Because even though perfectly legal it looks like a quick & dirty shorthand to spare typing a comparison; and it can overload an identifier with two meanings, that of the numerical value (or address) and that of a condition, as if the variable had two data types.
What would you think of this (fiddled) snippet:
int NoRetries; NoRetries= SendMessage();
if (NoRetries)
{
}
as opposed to
if (NoRetries > 0)
{
}
C was lacking a boolean type in the old days, in my opinion a design flaw. That made the aforementioned rule perfectly relevant. I prefer making the booleans explicit and highlighted.
In a moderatly pedantic style, this would give us
bool Retried= NoRetries > 0;
if (Retried)
{
}
|
|
|
|
|
I absolutely agree with you and consider using the a-zero-int-value-is-a-bool-false feature of C/C++ to be sloppy. Valid, but sloppy. I consider it sloppy because 0 is a meaningful (and highly useful) value for an int.
However, with pointers, NULL is a meaningful value that indicates the pointer points to nothing, all other values are considered valid pointers. Using a pointer like a bool and checking if it is explicitly NULL are the same -- they are both asking if it points to anything. There is no other possible semantic interpretation.
Writing code that omits an explicit comparison to NULL is also more easier to upgrade if the pointer is switched to one of the boost smart pointer classes, something we've done a fair amount of over the years. Not that the compiler doesn't catch the now-invalid comparison, but then you have to touch all that code just to get the same semantic meaning.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Sorry, no exception even for convenience. An integer is an integer, a pointer is a pointer and a boolean is a boolean.
|
|
|
|
|
Maybe he saw this boolean[^], got confused, and wanted to "make sure".
|
|
|
|
|
Wow - that link is worthy of a top position in the Hall of Shame all by itself!
|
|
|
|
|
Hey, you're coding in a language that I don't use, but I'm totally with you. This is one of my pet peeves, too.
One of my languages is Visual FoxPro, which has the "Immediate IF" ternary function, IIF:
IIF(expr, a, b)
If expr is true, a is returned, otherwise b is returned. So what I see is people doing this:
MyBoolVar = IIF(SomeVar = 2, .t., .f.)
Which could be simplified to:
MyBoolVar = SomeVar = 2
Much cleaner. Or they expand it into a regular IF statement similar to what you posted. When I see this it does worry me. If programming should result from logical thinking and a programmer has trouble understanding logical values (boolean values), then should we wonder about the rest of their skills?
|
|
|
|
|
void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
}
This would be better if they returned it too. Nothing like getting back what you put into it.
bool setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
return NeedsUpdate;
}
|
|
|
|
|
The second is better than the first. At least if you're going to set the value in this ridiculous fashion, make sure that it worked.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Excellent, in addition this provides a way to test that assignment succeeded and was correct.
I would even suggest
bool setNeedsUpdate(bool update)
{
if ((update==true))
{
NeedsUpdate=true;
return NeedsUpdate;
}
else
{
NeedsUpdate=false;
return NeedsUpdate;
}
}
so that if the code has a logic flaw, the function never returns !
|
|
|
|
|
How about "if (!(forceSend==true))" ?
|
|
|
|
|
I fully agree. This kind of stuff makes the code SO hard to read. And so many people do this too - just look at all the examples you were able to find! Atrocious.
When will people learn to put spaces around their operators !?!?!
Clive Pottinger
Victoria, BC
|
|
|
|
|
Just ran across this in code I've been asked to maintain (no kidding):
if (((ucGlobalHeaterEnable & (1 << UC_BHOSE_HTR_ON) ) > 0) ? 1 : 0)
{
...
}
Unbelievable!
|
|
|
|
|
Rather indigestible indeed.
I couldn't resist rewriting this piece using bit fields (in my opinion a sadly underused feature in C):
struct tGlobalHeaterEnable
{
bool bHoseHtrOn: 1;
} sGlobalHeaterStatus;
if (sGlobalHeaterEnable.bHoseHtrOn)
{
}
|
|
|
|
|
A true classic. I got thought to not do this first weeks in programming class, before learning stuff like functions.
|
|
|
|
|
I'm with you on this one! Sometimes verbosity improves readability, but there are many cases where it's just dumb.
The first example is terrible:
bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}
More code & multiple exit points -- for zero benefit???!!!
This would be better:
bool is_queue_empty(void)
{
return queue_length == 0;
}
|
|
|
|
|
Over 9GB of log files in the log folder of one of our "technology partners"
now - request change in logging behavior or install bigger HD's? What's cheaper?
|
|
|
|
|
Yes, a common pattern. Log every totally uninteresting event, so that the real errors can't be found anymore. And if they are found, they provide little to no information which might give you a hint to what has happened. Who do they think wants to read that stuff?
I had a program that sent a mail with 'An error has occured in application XXX'. No more. No error message, no stack trace, no parameters, no further information. When that thing had a bad day, it flooded your mailbox with those messages.
And from the clouds a mighty voice spoke: "Smile and be happy, for it could come worse!"
And I smiled and was happy And it came worse.
|
|
|
|
|
In a previous job, we had a pretty good logging system. Every message had a location and severity level from 1 for crash bang to 9 for suicidal debug on nearly every step. The code monkeys were reasonably good at putting in logging at the right level.
The clients were pretty bad at setting the logging to catch level 9 for all modules. Figuring they can always filter out the crap later.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Wow... you can always delete the files... can you disable the logging?
|
|
|
|
|
Over 9GB of log fileS? Seems like you did a pretty good job. We got a xml log file that's 9GB. Opening it instantly crashes the server
And seeing what my company logs in other applications I suspect it's 9GB full of crap that wouldn't help any programmer to fix any bug
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
What makes a happy programmer?
|
|
|
|
|
A happy programmer happens when you see a flabbergasted look from your client, because you delivered something they thought was impossible, in a most amazing way.....
|
|
|
|
|
I bet a happy programmer isn't one who gets their post "Message Automatically Removed"
|
|
|
|
|
When it comes in ahead of schedule, under-budget, bug-free and is accepted by the client who offers you a large bonus for your efforts and a new contract.
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
Trolls[ ^]
|
|
|
|