|
ISomething something = listOfSomethings.Where(...).OrderBy(...).FirstOrDefault();
if (something != null)
{
return something;
}
else
{
return null;
}Oh no, how come you thought you could return something when it is null? That's a different null!
|
|
|
|
|
Saw similar in javascript last week:
function checkIfValid() {
var isValid = false;
if (doSomeOtherCheck()) {
isValid = true;
}
...
if (isValid == true) {
return true;
} else {
return false;
}
}
[Edit] Updated to show more content from the function.
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
That makes sense if valid is "true" (string) or 1 (int), but you want to return a boolean 
|
|
|
|
|
I should have wrote that further up the function, isValid is set to either true or false
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
|
Using the "null" keyword in code should produce a compilation error. Not that it would break enything, right?
|
|
|
|
|
Maybe it is work in progress and the something should get some calls in the future...
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Actually they are different things, kind of. The FirstOrDefault is going to return
default(ISomething)
Your assertion that "something" is going to be null is actually an assumption. The code would indeed be redundant if it was this
ISomething something = listOfSomethings.Where(...).OrderBy(...).FirstOrDefault();
if (something != null)
{
return something;
}
else
{
return default(ISomething);
}
however we're getting into new levels of pedantry here  I sometimes write things like in the OP if I want to make it explicitly clear that it is expected that the function can return a null value.
|
|
|
|
|
F-ES Sitecore wrote: The FirstOrDefault is going to return default(ISomething)
Not necessarily. Assuming ISomething is an interface, default(ISomething) will be null. But:
interface ISomething { }
struct Something : ISomething { }
var listOfSomethings = new List<Something>();
ISomething result = listOfSomethings.FirstOrDefault();
Console.WriteLine(result == null);
For an empty sequence, FirstOrDefault returns default(TSource), where TSource is the type parameter of the input sequence.
And if ISomething isn't an interface, then whoever wrote the code needs to be introduced to the clue-bat.
Now that's a new level of pedantry! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
A-H are my replacements of more descriptive types to anonymize this drech slightly. I left the misspelling in.
public string getTransactionType(string TransactionType)
{
if (TransactionType == ("A"))
{
TransactionType = "1";
}
else if (TransactionType == ("B") || TransactionType == ("C"))
{
TransactionType = "3";
}
else if (TransactionType == ("D") || TransactionType == ("E") || TransactionType == ("F"))
{
TransactionType = "4";
}
else if (TransactionType == ("G"))
{
TransactionType = "5";
}
else if (TransactionType == ("H"))
{
TransactionType = "6";
}
return TransactionType;
}
Now granted, the point is to return a code given a type. But the method is misnamed, the way it's done is horrid, and what's worse, the now encoded type is used everywhere else in the code for conditional logic so you have no idea what the logic is doing without this piece of the type-code map.
And putting strings in parenthesis definitely improves the confidence of the equality test!
Marc
|
|
|
|
|
What happened to 2 
|
|
|
|
|
Wastedtalent wrote: What happened to 2
That was yesterday - see previous post. I just didn't put "day 2" in the subject line.
Marc
|
|
|
|
|
|
The first rule of Transaction Type 2 Club is: ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Wastedtalent wrote: I meant transaction type
 Oops. Don't know. I'll have to see if it's every used in the code!
Marc
|
|
|
|
|
I hope you're on a good day rate plus cleaning bills. I can see a lot of coffee getting spilt.
veni bibi saltavi
|
|
|
|
|
"genearte" - Typo on the first line. This is gonna be a good one.
string getTransactionType(string TransactionType) - So it's just a return statement?
.....
Oh how wrong I was 
|
|
|
|
|
Find a positive way of looking at such code: there is no need to waste money for an obfuscator!
|
|
|
|
|
Good lord ... below is how this might be worked out in Visual Prolog. This sure looks easier to understand, debug and maintain (extend).
class predicates
getTransInt : ( string ) -> integer determ.
clauses
getTransInt( S ) = I :-
I = transStrInt(S), !.
getTransInt( S ) = _ :-
stdio::write( "\nUnknown transaction string: ", S ),
fail.
class predicates
transStrInt : ( string ) -> integer determ.
clauses
transStrInt( "A" ) = 1.
transStrInt( "B" ) = 2.
transStrInt( "C" ) = 2.
transStrInt( "D" ) = 4.
transStrInt( "E" ) = 4.
transStrInt( "F" ) = 4.
transStrInt( "G" ) = 5.
transStrInt( "H" ) = 6.
|
|
|
|
|
I trust there is sarcasm in there. I can read this and get that it is similar though wrong if based upon the original code snippet - nothing in the original maps with 2.
The original code snippet is certainly not the most elegant; however, it would be clear to anyone looking at it what is being done: my dog would be able to figure out that code (and quite possibly have written it). Prolog is much more of an "acquired" taste.
Personally, while I try to make code look a little better than the original author did, the important concept (over efficiency and elegance) is that the next poor schmuck who needs to maintain that code can determine what it is doing very quickly. Usually, the time code needs modified is when something has broken and the results were already needed but were prevented by such failure. At such times, while trying to determine what the various pieces of code do, elegance has NO value; efficiency has NO value. Only being able to determine what the code is trying to do is of ANY importance, so CLARITY is paramount.
|
|
|
|
|
See how easy it is to spot errors when you use table-lookup code!
|
|
|
|
|
Unfortunately, such code is still being written.
I came across something like that last year (written just weeks earlier).
This one is actually pretty clean compared to that one.
It had about 10 types and each type could results in 3 actions, so that was an 10x3 if else branch 
Why don't these programmers ever stop to think "just because I can does it mean I should?" 
Or maybe they do, but their lack of knowledge prevents them from coming up with anything better and their lack of knowledge about their lack of knowledge prevents them from asking someone else for help...
Ignorance is bliss and crappy code I guess.
|
|
|
|
|
Maybe a bit masochistic, but I'm waiting for the next one. 
|
|
|
|
|
This code just leaves me speechless. It's wrong for so many reasons, and shouldn't actually even exist.
public static string PadStrg(string value, int length, char padValue, pad Pad)
{
if (value == null)
value = string.Empty;
StringBuilder sb = new StringBuilder();
string returnString = string.Empty;
if (Pad == pad.Right)
{
sb.Append(value.Trim());
sb.Append(padValue, length);
returnString = sb.ToString(0, length);
}
else
{
sb.Append(padValue, length);
sb.Append(value.Trim());
returnString = sb.ToString(sb.Length - length, length);
}
return returnString;
}
Marc
|
|
|
|
|
We'll pray for you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
