|
I downloaded some code of the internet which is used as part of Firefox, OpenOffice etc, compiled it and it produced a few warnings. I'm not a fan of warnings so thought I'd have a look to fix it...
if (((rv) &&
( checked_prefix || (words && words[wnum]) ||
(compoundflag && TESTAFF(rv->astr, compoundflag, rv->alen)) ||
((oldwordnum == 0) && compoundbegin && TESTAFF(rv->astr, compoundbegin, rv->alen)) ||
((oldwordnum > 0) && compoundmiddle && TESTAFF(rv->astr, compoundmiddle, rv->alen))
|| ((langnum == LANG_hu) && hu_mov_rule && (
TESTAFF(rv->astr, 'F', rv->alen) || TESTAFF(rv->astr, 'G', rv->alen) ||
TESTAFF(rv->astr, 'H', rv->alen)
)
)
) &&
(
scpd == 0 || checkcpdtable[scpd-1].cond == FLAG_NULL ||
TESTAFF(rv->astr, checkcpdtable[scpd-1].cond, rv->alen)
)
&& ! (( checkcompoundtriple && scpd == 0 && !words && (word[i-1]==word[i]) && (
((i>1) && (word[i-1]==word[i-2])) ||
((word[i-1]==word[i+1])) )
) ||
(
checkcompoundcase && scpd == 0 && !words && cpdcase_check(word, i)
))
)
|| ((!rv) && (langnum == LANG_hu) && hu_mov_rule && (rv = affix_check(st,i)) &&
(sfx && sfx->getCont() && ( TESTAFF(sfx->getCont(), (unsigned short) 'x', sfx->getContLen()) ||
TESTAFF(sfx->getCont(), (unsigned short) '%', sfx->getContLen())
)
)
)
) {
}
In fairness, it's the first time I've seen so many comments inside an if statement! Think I'll live with the warning (i.e. disable it for that particular file.)
|
|
|
|
|
This is simply ridiculous.. 
|
|
|
|
|
33 lines long condition in this piece of code is absolutely adorable!
A drunk disassembler would have done a better job generating such code  No kidding - recently, I had to restore some source code from a compiled dll, and reflector's result was way more reasonable than this one.
|
|
|
|
|
I've never seen this code before but assume it must be TKSpell. Yes, it's a horribly long conditional, but the code layout and comments make it reasonably clear as to what's happening.
I know that i'm going to offend a lot of people, but a large function is not, repeat not, in itself a sign of bad programming. If the routine does exactly one well defined thing, it doesn't matter how large it is counting lines of code.
And now i hear the refactoring crowd shouting at me. OK guys, you spend your time refactoring. I spend my time producing good solid production code.
|
|
|
|
|
Sam Cragg wrote: )
)
)
)
IHMO this is the best part of it.
Greetings - Jacek
|
|
|
|
|
The layout is not pretty and I would have commented it a lot more thoroughly, but there is nothing wrong with a complex if statement. I know that the refactoring polizei will feel that 1000 statements are better than one but as long as the code is well laid out and well commented (which this isn't), then a single statement can be simpler to follow.
The warning, incidentally, is for the final stanza in the line after the comment // LANG_hu section: spec. Hungarian rule. The compiler is guessing that rv = affix_check(st,i) should be rv == affix_check(st,i)
|
|
|
|
|
Why is it that people keep asking the same questions on the Q/A forums?!!!! It's appalling and tedious the number of people who can't be bothered just to search CP articles and old Q/A's!! The current recurring question appears to be how to send email in C#...can people pleeaasee search!? It's awful practise not to! 
P.S. Sorry I had to rant...and CP Lounge is blocked from where IO am atm... 
|
|
|
|
|
Yes, I understand you, and many other questions would deserve the standard RTFM reply, but in these cases I am usually happy just downvoting them.
Edit: Thank you. I was just wondering how long would be to get this post downvoted. 
modified on Thursday, March 3, 2011 8:41 AM
|
|
|
|
|
Search code-project articles or stack-over-flow << for me, this works in most cases.
there are many dumb people, who don't even search properly. I meet them at my office.
|
|
|
|
|
If they couldn't be bothered to google for answers, do you really think they'll bother to search this site.
They would have to move their mouse all the way to the top right of the menu bar, click, and then actually type in a search. Oh yeah... they would also have to click on the magnifying glass button...
Way too much effort involved...
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Yes true but instead they can be bothered to go to the menu bar, click the post question link, type in their question, tag it, write the body (well sometimes they can't be bothered with that  ) and then click the post button and then spend ages waiting for an answer...surely searching is less effort? 
|
|
|
|
|
No, searching requires at least some thinking, which the worst of them do not want to do. That is why they re-ask the same question when someone only gives them links to descriptions of how to do something. They want complete, fully functional and debugged code. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Very true A bit sad though when you think about it... 
|
|
|
|
|
I'm guilty of doing this, admittedly. Or, I'll do a search and can't find it, post the question, and a few hours, search again.
It would be that on the second search I find what I'm looking for...  Live and learn, I guess.
|
|
|
|
|
drummerboy0511 wrote: It would be that on the second search I find what I'm looking for
Maybe you have just found an answer to your own post -- googlebots are fast.
Greetings - Jacek
|
|
|
|
|
So, I recently changed jobs (4 months ago) and have found some humorous legacy code in the past. But nothing, nothing comes close to the database horror I found. For several days, the senior architect and my manager have been trying to figure out why our nightly and weekly stored procedures were taking so long as to time out. As it turns out, neither have and dba experience.
Well today the discussion turned to hiring an outsider to audit the tables, index, stored procedures, etc. I kindly volunteered to have a look myself, kindly pointing out my database experience. After 15 minutes I found the problem.
There is a table called trades, it has ~23,000,000 rows, and is almost always queried by tradeid and date columns. Not surprisingly the primary key consists of tradeid and date. I looked at the indexes and was shocked to see that there was a clustered index made up of open_quantity and order_type; values of which are almost always 0 and 0 or 1 respectively and almost never search criteria. I looked back at the primary key, and it was set to non-clustered.
This table has existed as such for years- recording and reporting positions and trends on a public facing website the entire time.
I was told I earned my pay for the week, but I'm not allowed to just go home 
Update:
We created a clustered index on the id and time column and kept the original clustered index as a non-clustered index. It did solve the problems we were having, primarily when inserts were extremely fast, select queries would become impossibly slow.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
modified on Tuesday, March 22, 2011 10:30 AM
|
|
|
|
|
You should have mentioned how much you have saved them getting in an external auditor to do the job and claim that as a pay bonus!
Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away
|
|
|
|
|
We get an evenly distributed monthly bonus based on the profitability of our department. Technically, since I saved that cost, the extra profit should be reflected in the monthly bonus pool for everyone. But yeah, I feel entitled to a little more of it this time around. I will probably poke around and bring it up once word gets out the major problem was fixed.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
sounds like a good scheme in general
Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away
|
|
|
|
|
Think of it this way... you get the respect of your peers. 
|
|
|
|
|
I wouldn't think the clustering vs non-clustering would not be a very big problem. The open_quantity and order_type index could be useful if the goal is, for example, to process all orders which have not yet been processed. Rather than scan 23,000,000 rows, you'd only have to process the 10 unprocessed orders. You sure you found the problem?
|
|
|
|
|
The open_quantity is never a search criteria. Its value is 0 99.99% of the time, and we never search by open_quantity or order_type, if we did, the order_id and date would be included as well. Have you ever inserted large sets of data into a table that had a clustered index, while the inserted data would have to be physically stored into the middle of the table because of the index? It's quite ugly.
I'm not suggesting eliminating the clustered index, but there's no reason the data need be physically stored in order according to open quantity and order type.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
You are right, there's not really a good reason to store that type of data using a clustered index. Still, I don't see anything that you've come across which would fix the problem you described. Would inserting a value with a bad clustered index cause all the rows in the table to be moved so that the physical location on the hard drive is stricly enforced (i.e., so rows will be ordered on the HD by the clustered index)? Or is SQL smart enough to insert the data without rearranging it (i.e., by using a tree-like structure)?
|
|
|
|
|
Clustered indexes physically store the rows in the order provided by the index, as far as I know, it can be quite taxing on resources so I'm not sure what logic they use for it.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
See here. Basically, the row data is stored with the clustered index, which is stored as a B-tree, so insertion is not an expensive operation (i.e., this should not be the cause of your problem).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
