|
But then why not
do
{
...
} while ( false ) ;
|
|
|
|
|
|
heh.
of course that's just a coding-standards-compliant way of writing:
if (set (ifrFragment))
{
result = true;
ifrTerm = ifrFragment;
goto done;
}
if (errorCode)
goto done;
if (keyword (TokenSubtype::Not) && term (ifrFragment))
{
result = true;
ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment;
goto done;
}
if (errorCode)
goto done;
done:
|
|
|
|
|
|
You're sure you're not mistaking that "one" in lnIndice <= 1 for an "ell"?
Marc
|
|
|
|
|
Only a real programmer who codes in raw hex, or someone very daft, or someone with the editor font set to one with massive differences between 1 and l would ever call a variable "l".
i, on the other hand...
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
That's what I call extendable coding. 
|
|
|
|
|
FINALLY!!!!
My first entry on a coding horror!
Is this a sign I am starting to learn, possibly, but even in goood old fashioned ms basic circa 1981 I would have spotted this load of old codswallop!
So pleased to say that I would never have done this!
------------------------------------
Happy Primes Lead to Happy Memories.
Don't Google FGI
|
|
|
|
|
heheheh . Cool thing....i myself as developer can understand that sort of things can happen when code passes through certain hands without proper comments.
|
|
|
|
|
Whether it was the basement of great code or the ruin of an unlucky project. Who knows... 
A good optimized cempiler would clean this up. 
Greetings from Germany
|
|
|
|
|
omg.. what else is there to say ?? 
Michael Davey
biproject.com rss and blog news in a more palatable format
mobile edition now available!
|
|
|
|
|
- Pascal - wrote: We found it very funny
I find it quite useful, actually. This is the sort of thing that sits in code that is prone to change. Why destroy the entire structure when a month or two from now, someone has a need to add in an index of 2 and 3?
Though, admittedly, I'd comment out everything but the 'do something' code when it got this low. But I'd still leave it THERE.
|
|
|
|
|
I was cleaning up the code in a parser. There is a switch/case statement that spans over 2,200 lines. I removed a bunch of exits from various case statements and moved it up as a global test on the errorCode.
It just didn't want to exit when the errorCode was set.
state=1;
do
{
result = token( tokstr, FALSE, NULL, FALSE);
switch(state)
{
if (errorCode != 0)
return FALSE;
case 1:
switch(result)
{
}
} while( result != Keyword::EOFTOK );
“Although distant in time, Homobonus does in fact figure as a saint for the Church and society of our time.”
-- Pope John Paul II
|
|
|
|
|
2200 lines of cases? Impressive, at least to me, humble employee of small companies.
|
|
|
|
|
Oshtri Deka wrote: 2200 lines of cases? Impressive, at least to me, humble employee of small companies
I'm not happy with 2200 lines of cases. I'm seeking to clean this up and reduce complexity. Things tend to just keeping growing.
I'm curious, do you see the problem with my posted code?
|
|
|
|
|
I was sarcastic, though I am impressed that someone wrote so many lines of code for one switch-case block. What does that application do?
checking before first case?
|
|
|
|
|
Oshtri Deka wrote: I was sarcastic, though I am impressed that someone wrote so many lines of code for one switch-case block. What does that application do?
That module has to do with parsing a parameter file. It probably was state-of-the-art in 1983. It has just grown and grown. We need an option at to handle FOOBAR? No problem, add a #DEFINE FOOBAR 1742 and one more case statement.
Continue the process for almost a quarter century.
The application classifies inpatient hospital records into disease categories and stages of the disease. The portion of the program that does that has been modernized.
checking before first case?
Yeah, that code was unreachable. I checked it into source control. It worked great if there were no errors. 
|
|
|
|
|
You should construct a data structure and keep the possible values in case statements in an ordered way in your data structure; then your incoming value should be compared with the values inside your data structure in binary search fashion...
this will be faster and save you from time consuming sequential searching
|
|
|
|
|
xenonysf wrote: You should construct a data structure and keep the possible values in case statements in an ordered way in your data structure; then your incoming value should be compared with the values inside your data structure in binary search fashion...
this will be faster and save you from time consuming sequential searchin
I agree with what you say but not for the reasons you give.
A switch/case statement has better performance than a sequence of if/else statements. The compiler may generate a jump table. For large tables, some use binary searches. See http://www.eventhelix.com/RealtimeMantra/Basics/CToAssemblyTranslation3.htm[^].
So performance isn't the driving factor here.
But I do agree that the cases -- where possible -- should be encapsulated in a data structure. We would like to have actions for the various cases in a data structure to simply the logic.
Complexity leads to increased probability of error. We have unneccessary complexity. However, it takes a while to untangle code that has grown for decades.
|
|
|
|
|
switch(state)
{
if (errorCode != 0)
return FALSE;
case 1:
switch(result)
{
My guess is that execution jumps to one of case labels and skip the if statement entirely?
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
My compiler woud throw exception
|
|
|
|
|
bsaksida wrote: My compiler woud throw exception
Are you sure? I think it's legal C++ albeit stupid programming. I wish it had thrown an exception. But Visual Studio was happy with it, as were the compliers on AIX, Solaris, and HP/UX.
|
|
|
|
|
why is there a switch inside switch
This style of progrmaing introduce more compiling errors than the bugs
|
|
|
|
|
bsaksida wrote: why is there a switch inside switch
Well, it fits the logic. When the parser is starting a statement, the state is 1. Then it does a switch statement based on the first token.
The code all works, I'm just not happy with how complicated it is. I used SourceMonitor[^] to get a metric on the complexity.
Mike Swanson[^] suggests that <quote>Anything with a greater complexity than 10 or so is an excellent candidate for simplification and refactoring. Well, the code in question has a complexity number of 638 as measured by SourceMonitor.
You don't go from 638 to 10 in one step. So one of the things I did was to have a single exit with the error code at the top of the case statement. Or at least, I tried to. My logic error was a little embarrassing.
But an error like that is too good to keep to myself. I had to share it.
|
|
|
|
|
I have found, on several places in our app, code similar to this:
try<br />
{<br />
}catch{}
Do I need to say I have found that during urgent debugging session (important customer had had complaints)
Empty catch blocks, and most of them were in methods which deal with data.
Let's just say that we use multi-threading and reflection, a lot, and I spent too much time on only localizing this.
Why are people so reckless? I am far from being expert, but everyone who likes to think about oneself as a coder or developer should use common sense.
Notice: Somehow (perhaps in a state of fury) I have forgotten to describe places where I had found above mentioned problem, and that has made this post is a bit misleading.
Programmer who have written that code, used this "technique" only to sweep things under the rug!
No returning values, filling dataSets, no validation, allowing bad user input (constraint violations)... in short error-exception domino which occurs only in specific situations.
I am aware that empty try-catch block isn't excuse for witch hunt, but (at least) generally it isn't best practice. When I am not sure if something is preferable, I ask more experienced colleagues.
-- modified at 6:31 Tuesday 20th November, 2007
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
