|
Yep I agree reducing the DB access is definitely the best performance optimisation.
GibbleCH wrote: I use it everywhere since my variable names are clear
That's fair enough, I just prefer having the type declared at the start as it makes easier scanning IMO
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
|
|
|
|
|
musefan wrote: float.TryParse(cmd.ExecuteScalar().ToString(), out result);
That will throw a null reference exception if ExecuteScalar returns null.
|
|
|
|
|
just testing 
...perhaps you should put it in a new hall of shame post
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
|
|
|
|
|
Oh, no... We all make this kind of mistakes from time to time. However, the way you have corrected it would not work either. In this case ExecuteScalar would return null or a boxed value type, so checking its result with "as string" would always return null. I you don't use a nullabe type here you would have to use an object and check for null before trying to make any conversion, I mean:
object obj = cmd.ExecuteScalar();
if (obj != null)
I my opinion, nullable types are much cleaner for this.
|
|
|
|
|
musefan wrote: ...so how would you write that bit of code?
musefan wrote: Need to get it to a float somehow
int? result = (int?)cmd.ExecuteScalar();
return (float)result.GetValueOrDefault();
There is no need for esoteric conversions, Parsing or ToString at all. Actually, there is no need for an if in the original code posted, and if ExecuteScalar returns null, the original code would throw a null reference exception.
musefan wrote: What deserves a vote of 1?
I don't know, I did not downvote you.
Edit: Where you see "int?" I put "float?" before, and that was a mistake.
modified on Wednesday, March 2, 2011 6:18 AM
|
|
|
|
|
I think you where better of with float, what if SUM returns a double value? Plus int to float can be implicitly cast
I get what you are saying thou. I am not sure on the exact ins and outs of the performances of casting to nullable and using GetValueOrDefault() over an if null statement but I doubt it would be much either way so preference will get the job done
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
|
|
|
|
|
Yup, you are right, I was better with "float?". I did not read the query (as usual, I am soooo absentminded). The nullable type to use must be the one which fits with the one defined into the database, I mean, if the query is defined to return a float you cannot use "double?", becouse the unboxing operation would fail. Anyway, GetValueOrDefault is a constant complexity operation, so in these cases I usually choose the solution which gives me a cleaner implementation.
|
|
|
|
|
_Erik_ wrote: The nullable type to use must be the one which fits with the one defined into the database
I think a nullable float would still do the trick, even if the DB defined the value as decimal or numeric or int or float then the explicit case to float would still work, and as that is your retuning value anyway you need to cast to float at some point
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
|
|
|
|
|
No, that is not right. Just try this:
object obj = 1;
float? f = (float?)obj;
This would throw an exception. The value type boxed into the object in this case is an int, so you need an (int) or (int?) casting to unbox it. Any other type would throw the same exception. Remember we first have to unbox the value type, and the compatibility rules among numeric types are not applied for boxing-unboxing operations.
|
|
|
|
|
oh yes, correct again sir... lesson learnt
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
|
|
|
|
|
Straight out of a C# Unified Communications code sample from MS:
if (string.IsNullOrEmpty(customMessage.Trim()))
...
|
|
|
|
|
Looks like somewhen Trim() returned null when a string contained spaces only.
Or was it meant for Oracle compatibility (with Oracle, an empty string means null)?
|
|
|
|
|
Really funny. The check for a null string will throw a null reference exception is customMessage is null.
|
|
|
|
|
What is wrong with that? I imagine this was before .Net 4.0 in which you can now use string.IsNullOrWhitespace()...
if(string.IsNullOrWhitespace(customMessage))
...
Illogical thoughts make me ill
|
|
|
|
|
musefan wrote: What is wrong with that?
As _Erik_ said, what happens with this code?
string customMessage = null;
if (string.IsNullOrEmpty(customMessage.Trim()))
...
|
|
|
|
|
now that's shameful coding, but the OP never put that, there is no evidence that it is unsafe to assume that customMessage will never be null. What if the following was the case...
string customMessage = GetCustomMessage();
if (string.IsNullOrEmpty(customMessage.Trim()))
...
string GetCustomMessage(){
string result = GetSomeDataFromSomewhere();
return result ?? "";
}
Illogical thoughts make me ill
|
|
|
|
|
musefan wrote: there is no evidence that it is unsafe to assume that customMessage will never be null
If that was the case then the call to string.IsNullOrEmpty would not be required, as you could safely access the Length property and test for zero. Eitherway you look at it, the OP code is unnecessary 
|
|
|
|
|
But the whole point in the trim (IMO) is to test that a complete whitespace string is not confused with meaningful data. Imagine if the string was fetched using my sample method, and the call to get the data in there returns a tab separated list - this function may always end in a tab even when no data has been added. so the resulting value could be "\t" in which case it should be ignored just like "" would be.
Your length test doesn't work in this case because a string of data and whitespace would equal the same. Consider the following possible string values and what you want to test for invalid...
string s = "";
string s = "\t";
string s = @"data 1\tdata 2\t";
Illogical thoughts make me ill
|
|
|
|
|
Sorry, I don't think I phrased it well. The length test was a replacement for the string.IsNullOrEmpty call - you can still call Trim though. Back to the original code:
if (customMessage.Trim().Length == 0)
...
|
|
|
|
|
I see, yep that's OK with me 
My initial post was really to find out why it was such a bad line of code when we cannot see any other code to judge. People seemed to be going for the null exception but there was nothing to indicate that wouldcould happen
Illogical thoughts make me ill
|
|
|
|
|
However unlikely, things that CAN happen eventually WILL happen. Illogical or not.
|
|
|
|
|
I didn't say it was unlikely, I said it was possible that it could never happen. That does not mean sometimes it could happen, it means other code could decide that it will never happen.
oggenok wrote: things that CAN happen eventually WILL happen
...and that is not certain
if I wrote...
string s = "hello ";
s = s.Trim();
...would you correct with...
string s= "hello ";
if(!string.IsNullOrEmpty(s))
s = s.Trim();
EDIT: Not understanding my message is not justification to vote it down.
Illogical thoughts make me ill
modified on Tuesday, March 1, 2011 10:22 AM
|
|
|
|
|
Hey!
Found this evaluation if an object is from a certain sort in a Java code:
if(oSomeStringObject.getClass().getSimpleName().equalsIgnoreCase("String")){
doFunnyStuff();
}
 that's probably the worst attempt I've seen in a long time. I don't know exactly, but this might be from an C-Programmer trying to code Java. We are using some code given to us here.
regards
Torsten
I never finish anyth...
|
|
|
|
|
TorstenH. wrote: C-Programmer trying to code Java
Or maybe a .NET programmer (C# probably) who failed to find that Java "instanceof" operator is the equivalent to the C# "is" operator.
|
|
|
|
|
Here's another chunk of C++ that has been converted to VB.net:
Public Shared Function Strdate(ByVal dateBuf As String) As String
' timt(tnow)
'tm *tnowVals
'time(&tnow)
'tnowVals = localtime(&tnow)
Dim tnowVals As DateTime = DateTime.Now
tnowVals = DateTime.Now
If tnowVals.Year > 1999 Then 'If (tnowVals.tm_year > 99) Then
tnowVals.Subtract(TimeSpan.FromDays(365 * 100)) ' tnowVals.tm_year -= 100
End If
dateBuf = tnowVals.ToString("MM/dd/yy") 'sprintf(dateBuf, "%02.02d/%02.02d/%02.02d", tnowVals.tm_mon + 1, tnowVals.tm_mday, tnowVals.tm_year)
Return dateBuf
End Function
Notice that even the original C++ is faulty; it should use % (mod) rather than subtracting 100 years -- a Y3K bug. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
