|
It happens.
One site I was on had a developer add a "feature" that caused forum replies to be attached to a random post. He said that it was supposed to "liven up the forums". I don't think he works for that site anymore.
I'd post a link, but this was several years ago, and I can't remember what site it was.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Brisingr Aerowing wrote: One site I was on had a developer add a "feature" that caused forum replies to be attached to a random post. He said that it was supposed to "liven up the forums". I don't think he works for that site anymore.
Uhhhh.... yeah. How was that supposed to "liven up the forms"? The only way we're ever going to know that is to find out what drugs he was on and get some.
|
|
|
|
|
Makes sense if the only valid input is JUL or SEP
|
|
|
|
|
Porting some C code to one microcontroller to another I found this:
if((error == 0)
#ifdef SENSAR
|| (V_OK == 0))
#else
)
#endif
This work is unhealthy
|
|
|
|
|
How else would you do it? Other than, of course, eliminating the #else by putting the right-parenthesis outside the #if .
|
|
|
|
|
leaving V_OK = 0 whenever you don't define SEANSAR maybe.
If I could I would put all the code here for you to see what I have to strugle every day. There are violations to every single "good programing practice", starting for the encapsulation, with a lot of variables and defines mixed in separated and "isolated" modules.
|
|
|
|
|
But this way eliminates a test when you don't have SENSAR; ergo it's FFFAAASSSTTTEEERRR...
Why test something that's always true?
|
|
|
|
|
Maybe, but this things makes the code unclear and dificults the scalability.
Anyway you are right in the fact that it is faster, innecesarily and almost insignificaly faster
|
|
|
|
|
But when working with microcontrollers performance and memory management are important, aren't they?
And many small things might lead to a noticeable gain in that.
|
|
|
|
|
I was going to say that. Sometime had to do weird trick, that looked really ugly, just to save program memory (PIC16F84)
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
You're absolutely right. You ought to write it more concise:
if((error == 0)
#ifdef SENSAR
|| (V_OK == 0)
#endif
) Much cleaner now!
|
|
|
|
|
I would have write it that way.
#ifdef SENSAR
if((error == 0) || (V_OK == 0))
#else
if((error == 0))
#endif
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
I have to agree, it is easier to read that way.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
still has double parentheses on the 2nd case. That will slow the compiler massively
|
|
|
|
|
I didn't try to optimise, just to make it easier to read.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Such messie code is dangerous as gasoline. One error and everything blows up.
I wont accept such stuff from my collegues.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Doing some code clean up and found this gem
if ( flag && test_fn() )
{
if ( test_fn() )
{
}
}
test_fn() isn't particularly expensive ... but really?
|
|
|
|
|
So presumably test_fn looks something like this:
private int _testCallCount = 0;
public bool test_fn()
{
_testCallCount++;
return (_testCallCount & 1) == 0;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
At least it is not
if ( ((flag == true) && (test_fn() == true)) == true)
{
if ( test_fn()== true )
{
}
}

modified 19-Jan-21 21:04pm.
|
|
|
|
|
What if test_fn() does change a global such that, when the next time it runs, may not return true?
That makes perfect sense to call a function after already calling validating it.
I've set a flag that, when true, also calls a function within an If statement.
I once-again call the function to see if we're still good to go, especially in a parallel processing app that can change datapoints before another process gets to it.
I then recursion into the function during the function to ensure that no externals have changed while it is in process, for it calls additional functions.
And, if you believe I do all this, then hire me at $1 million a year and I'll gladly implement this into yer project!
|
|
|
|
|
MacSpudster wrote: I once-again call the function to see if we're still good to go
You really should be using locking :P
TVMU^P[[IGIOQHG^JSH A#@ RFJ\c^JPL>;"[, /|+&WLEZGc
AFXc!L<br />
%^]*IRXD#@GKCQ R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_ADEPABIKRDFVS)EVLQK)JKQUFK[M UKs$GwU#QDXBER@CBN%
R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
-----------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
I totally agree
modified 19-Jan-21 21:04pm.
|
|
|
|
|
May be this poor guy think that check test_fn() 1 time is not True enough, and he do it twice just for sure
In code we trust !
|
|
|
|
|
The application I'm newly tasked with maintaining is a large heap of WTF, but I picked this problem out to share because it demonstrates the supreme barrier to understanding that the prior developer(s) have constructed:
#define __2__
#if __2__
#else
#endif
Actually, there are many comments all over the code, but of the sort that tell you absolutely nothing:
if (max > -1)
{
...
}
Why name that variable maxCsvPosition when a careful analysis of the dozens of lines of surrounding code will tell you that? What are you, lazy? And even dozens of lines is often a luxury—many of the methods in this thing are many hundreds of lines long! The variable names are typically like the following, their scope often spanning many screens' worth of code:
ed1
s
sd
p
pd
Shouting curse words with great frequency has become my new affect here at t'office.
I despair 
|
|
|
|
|
Variable naming rule 0) You don't have to name the variables you don't create.
|
|
|
|