Absolutely I would feel uncomfortable. But not for the reason that some people seem to be imagining. It's because it makes me think that they're storing my password in plaintext. Basically, I can think of two ways that my password would be case insensitive. a) is deliberate - they uppercase (or lowercase) it before hashing it. It seems pointless and silly to do this, but it causes no great loss of security. b) is accidental - they're storing my password in plaintext, and SQL string comparisons are case insensitive by default. The tendency to believe b) is what makes me uncomfortable.

ii_noname_ii wrote:

Finding what you search for is the goal. Searching doesn't mean you'll find it.
Therefore, find > search. The term "find" gives a user more confidence.

And when I click "Find" and you tell me "no results found," you've lied to me. You can't promise that you'll find what I'm looking for. The best you can do is search for it.

Zac Greve wrote:

#if DEBUG //DEBUG CODE #else //RELEASE CODE #endif

True, and I do that a lot. Though it's bit me a couple times that I now watch out for... a) In most situations I'd really rather have 3 levels - DEBUG on my dev machine, DEBUG on the dev server, RELEASE on the production server. b) Release code paths don't get tested as thoroughly until uploaded to the production server. I mean - you have to test them, but if you wrap everything in #if DEBUG directives, it can be nontrivial to run in VS on a dev system in RELEASE mode.

Simple rationale - running this on a test system and the last day that the test system has data for is 4/26. A quick change to the code for debug purposes, just make sure to roll it back before release... oops!

CDP1802 wrote:

Ironically, assingning zero to a variable of a numeric type is the most unproblematic case of all, since it turns out to be one or more zero bytes, no matter if we are looking at an integer type, a floating point type, signed or unsigned.

That's definitely true of assigning 0 to a variable. But there's a related case that's problematic: sqlParams.Add(new SqlParameter("Quantity", 0)); Acutally assigns the "Quantity" parameter a value of null, because apparently this fits the definition for

SqlParameter(string parameterType, SqlDbType dbType)

better than it does for

SqlParamter(string parameterType, object value)

because 0 is a valid value for the enum SqlDbType and any match is a better match than object. To assign a value of 0, you have to do: sqlParams.Add(new SqlParameter("Quantity", Convert.ToInt32(0))); (as for why you would do this... well, I'd rather not go into it...) So maybe the original coder was confused by that very specific case? ...probably not...

Collin Jasnoch wrote:

if(_globalBannnaOrderView == null) { _globalBannnaOrderView = new BannaOrderView(); ... } else { _globalBannanaOrderView.Focus(); }

Are _globalBannanaOrderView and _globalBannnaOrderView different variables, or just a typo? Because doing that on purpose would be an even worse Coding Horror. :-D Also, if you mean the fruit, it's spelled Banana. Not that it really matters, but it might be easier to be consistent... (I see Banna, Bannna, and Bannana in just the quoted section)

P1l19r1m wrote:

#define TRUE (rand() > 0.1 ? TRUE : FALSE) // happy debugging losers :)

Shouldn't that just be #define TRUE (rand() > 0.1) ? I guess I haven't used c++ in a while, but what happens when you use a circular define like that?