I'm glad to say that i like this code :-) No horror there i my opinion.
- oggenok
I'm glad to say that i like this code :-) No horror there i my opinion.
- oggenok
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.
However unlikely, things that CAN happen eventually WILL happen. Illogical or not.
Straight out of a C# Unified Communications code sample from MS:
if (string.IsNullOrEmpty(customMessage.Trim()))
...
"object-oriented design is the roman numerals of computing." -- Rob Pike
I like that! A former collegue of mine had a tendency to use very long and elaborate variable/function/method/property names. One day i invented an unused property called __AVeryLongAndLargelyUnusedProperty_PKA. PKA being his initials. Need i say that i forgot all about it. The thing went into production, until years later PKA one day yelled at me: What the shikes is this?
Holy Lord.
Looks like an ideal case for some loop unrolling. If say bmp.Width is always even, the inner col loop could be rewritten as
for ( int col = 0; col < w; col += 2 ) {
*imgPtr++ = *b++;
*imgPtr++ = *g++;
*imgPtr++ = *r++;
*imgPtr++ = *b++;
*imgPtr++ = *g++;
*imgPtr++ = *r++;
}
saving half the overhead of loop management. C# doesn't allow fallthrough in switch statements, otherwise Duffs device would be perfect here. - turin
You need to open a TAPI-device before you can receive any events - use lineOpen. Most likely you will wan't to preceede that with lineNegotiateAPIVersion and lineGetDevCaps.
Now i understand why they call it careless return :-) - turin
Yes, it should most definitely be doing this! What you are assigning to a variable is a bit pattern - not a value. Whether the variable is signed or not is a question of interpretation. Your interpretation! Assigning a negative constant to an unsigned variable is perfectly legitimate. As Tim Craig pointed out, you should trust your beloved and most obedient servant - the compiler. All compilers will warn you about signed/unsigned mismatch. - turin
Straightforward Basic code and not even close to a horror in my opinion. The purpose of the routine is clear, there are no wacky algorithms, and it's easy to locate an error, if say a "j" is not being displayed correctly. And yes, I know that "Else If" would have been preferable and a "Select ... Case" even better.
Future enhancement perhaps.
I love it! Being on holliday, i can't wait to get back to implement this wonderful scheme. - turin
What i really like the most is the "Err_Handler". So beautiful, so classical, so elegant :-)
No, you are not standing in shame. A great many people have bitten by trigraphs because they are so counterintuitive.
The string literal "??)" will be replaced with the single character ']' which looks consistent with what you've seen. I don't have VS around so i can't immediately reproduce the output. By default gcc ignores trigraphs, so it's not a surprise you don't see the "problem" there. Try compiling with the -trigraphs switch.
Ye olde trigraph strikes again. It's well documented in my old Kernighan & Ritchie: "The C Programming Language", 2nd edition from 1988.
No, i'm not working in the financial sector. And yes, my example was a reporting system having read-only access to everything - not just implementing a SP but also to your savings account :-)
Using an SQL IN-clause is definetely not a design flaw. Forcing everything into JOIN's is on the other hand an odd self-imposed hinderence.