|
I should add, for fairness, that many of those "dim bulbs" I referred to are, in fact, sophisticted experts in their own fields...but they are not computer scientists. FORTRAN, the first high-level programming language, was created so that scientists could write complex calculations without having to learn anything about the inner workings of the computer they were using for the calculation. COBOL was created with a similar intent for business and administrative purposes. C was created so that a portable language existed for computer experts that allowed one to program directly on the computer without having to use assembly language. In fact, some of the dialects of C I used in my early career contained primitives for directly address CPU registers, and most of them contained facilities for allowing in-line assembly language blocks; I may be wrong, but I doubt that you've had a use for either of these facilities in your academic career to date
|
|
|
|
|
Hey, you two are really keeping this thread going! Wow.
Meanwhile, as an aside, modern C and C++ compilers still provide the capability for inline assembler code (the MS compiler defines __asm as the keyword for doing this, other compilers may use asm, _asm, etc). The ability can come in handy for performance critical areas if you don't care about portability across processors. I'll also note that the quality of code put out by modern compilers is making the usage of inline assembler not the necessity it used to be (depending on the application, of course).
|
|
|
|
|
I see a lot of:
if (b1)
b2 = true;
else
b2 = false;
and even some:
switch (b1)
{
case true:
b2 = true;
break;
case false:
b2 = false;
break;
}
|
|
|
|
|
David St. Hilaire wrote: I see a lot of:
if (b1) b2 = true;else b2 = false;
and even some:
switch (b1){case true: b2 = true; break;case false: b2 = false; break;}
You have my sympathies.
|
|
|
|
|
... have to work with people who wrote this GEM
if(i==0)
*outcallRecvCount = 0;
else
*outcallRecvCount = i ;
C++ where friends have access to your private members !
|
|
|
|
|
eh... ahem...
you're using plural... so there's more than one...?
(yes|no|maybe)*
|
|
|
|
|
I don't actually see something wrong with this.
I could be that that i changes between
if(i==0)
and
*outcallRecvCount = i;
But then they should have protected it with CRITICAL_SECTIONS
Learn from the mistakes of others, you may not live long enough to make them all yourself.
|
|
|
|
|
Well, IF the variable did change the code would make a bit more sense.... I believe what he meant was the pattern
if (someCondition)
doSomething();
else
doExactlyTheSameThing();
|
|
|
|
|
BadKarma wrote: But then they should have protected it with CRITICAL_SECTIONS
There is only one situation where I would expect to see code like this: when one wants to set a breakpoint at i == 0 in the debugger, and one doesn't want to slow execution within the debugger by creating a conditional breakpoint.
|
|
|
|
|
Gin for breakfast. That should sort it out.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
It would have been clearer if the if ( ... ) had been expanded upon. You know something like this,
if ( i == 0 && *outcallRecvCount != 0 )
*outcallRecvCount = 0;
else
if ( i != *outcallRecvCount )
*outcallRecvCount = i;
There that's much clearer and couldn't possibly be considered a horror.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
That's legitimate, because the author needed
*outcallRecvCount = 0;
instead of
*outcallRecvCount = 0 ;
on
i==0
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Oh I see it's the space before the semi-colon...
|
|
|
|
|
Exactly.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Lovely!
What is even more disgusting is that I've seen similar code in the product I am working on. You know, things like:
if (thisBoolVar == true)
{
thatBoolVar = true;
}
else
{
thatBoolVar = false;
}
It is quite painful to have to be in areas of this code...
|
|
|
|
|
And people ( especially non-programmers/managers ) don't understand why I say that just because it seems to work doesn't mean that it is good code.
Bill W
|
|
|
|
|
Very true. However, I don't want to make it seem like all managers are lumped into the non-programmer's category. Every so often, in some companies more than others, you'll have managers that are technically savvy and do understand the realities of the code base. It's a pleasure to work with these managers, even if they can't fix the world (because of the dictates of managers above them, etc).
|
|
|
|
|
I have to admit that is true. Some managers do understand, usually the ones that were programmers themselves, but sometimes the non-programmers do "get it".
Bill W
|
|
|
|
|
My first manager was technically savvy. He was a software engineer and has written many of the earlier versions of the software. It was lovely technical discussion. But he sucked as a manager / leader, just following orders from the top
He would come and tell us what is going to happen and expresses his frustration and disagreements. poor fella, can't he fix the world?
Yusuf
|
|
|
|
|
CIDev wrote: And people ( especially non-programmers/managers ) don't understand why I say that just because it seems to work doesn't mean that it is good code.
Sometimes, when I tell a manager about the Obscure C contest, tne light goes on
|
|
|
|
|
|
We can build upon this!
try
{
if (thisBoolVar == true? true : false)
{
thatBoolVar = (thisBoolVar != false? true : false);
}
else
{
thatBoolVar = (thisBoolVar == false? false : true);
}
}
catch {}
if (thatBoolVar != thisBoolVar) ...
|
|
|
|
|
There's a slim chance that the author was trimming some code now and had reason to believe additional code would be added. (Though a comment to that effect would have been useful.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
You must be new to this coding thing... you will see stuff that's far worse.
|
|
|
|
|
pretty much sums it up.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|