c# curious inline if question

[Necuno]

expiryDateText is read as the text value of 1/12/2009

a)
DateTime? expiryDate = (string.IsNullOrEmpty(expiryDateText)) ? new DateTime?() : DateTime.Parse(expiryDateText);

b)
DateTime? expiryDate = (!string.IsNullOrEmpty(expiryDateText)) ? DateTime.Parse(expiryDateText) : new DateTime?();

c)
DateTime? expiryDate = (string.IsNullOrEmpty(expiryDateText)) ? DateTime.Now : DateTime.Parse(expiryDateText);

d)

DateTime? expiryDate = null;
if(!string.IsNullOrEmpty(expiryDateText)) expiryDate  = DateTime.Parse(expiryDateText);

now you would think that all 4 would yield the same result but no it doesn't. a and b always gives a null regardless if expiryDateText has a value or not. c and d however sets value as a parsed date from the string.

seems that the compiler/ide doesn't like it when new DateTime?() is used inline and goes null for some reason each time

 

[Rouxenator]

Inline evaluation is something we have banned from being used as part of our company's coding standards.

It complicates things unnecessarily.

 

[guest2013-1]

WTF does the "?" mean?

 

[gboy]

i know C# pretty well, but WTF, try stop using short hand to write your code, you dont charge per line

 

[guest2013-1]

i know C# pretty well, but WTF, try stop using short hand to write your code, you dont charge per line

If they did then he'd do better by breaking it up into several lines...

 

[hyperian]

WTF does the "?" mean?

They're using the ternary operation:

int a = 1;
int x = a > 0 ? 0 : 1;

that's the same as:

if (a > 0)
{
x = 0;
}
else
{
x = 1;
}

http://en.wikipedia.org/wiki/?:

 

[Saajid]

now you would think that all 4 would yield the same result but no it doesn't. a and b always gives a null regardless if expiryDateText has a value or not. c and d however sets value as a parsed date from the string.

seems that the compiler/ide doesn't like it when new DateTime?() is used inline and goes null for some reason each time

a) and b) are equivalent, which is why you get the same result. You've just inverted the logic. They are semantically exactly the same.

I

It is correct to for it to have a value of null, because new will return the default value, since it's a nullable type, that's null

Dequadin is right. That is the correct behaviour.

Inline evaluation is something we have banned from being used as part of our company's coding standards.

It complicates things unnecessarily.

That's just silly. Whether you use inline evaluation, and the ?: operator, or a lengthy, nested if else statement, the compiler will still spit out the same IL code. Don't blame the language or compiler because the developers have a poor understanding of it. Inline code actually saves me a lot of time, and helps with readability. Besides, all the new Microsoft Technologes, like ASP.Net MVC, Lamda Expressions, and Linq-to-Sql, actually make MORE FREQUENT use of inline expressions. It's just silly to blanket ban it.

Oh, by the way, you should NEVER NEVER use DateTime.Parse() Always use DateTime.ParseExact() or even better, DateTime.TryParseExact, to prevent the exception from being thrown:

DateTime articleDate = DateTime.MinValue;
if(DateTime.TryParseExact(date, "dd MMMM yyyy", null, System.Globalization.DateTimeStyles.None, out articleDate))
{
// do something
}

Just do a google search about DateTime.Parse() and how bad it is. It will often return to you the wrong date - as it tries to guess the date if the string you provide it is not unambiguous. DateTime.TryParseExact() will fail for ambiguous cases (09/11/09, 11/09/09, etc), which is the correct behaviour.

 

[Necuno]

I just tested this:

string expiryDateText = "1/12/2009";
DateTime? expiryDate = (string.IsNullOrEmpty(expiryDateText)) ? new DateTime?() : DateTime.Parse(expiryDateText);
DateTime? expiryDate1 = (!string.IsNullOrEmpty(expiryDateText)) ? DateTime.Parse(expiryDateText) : new DateTime?();
DateTime? expiryDate2 = (string.IsNullOrEmpty(expiryDateText)) ? DateTime.Now : DateTime.Parse(expiryDateText);
DateTime? expiryDate4 = null;
if (!string.IsNullOrEmpty(expiryDateText)) expiryDate4 = DateTime.Parse(expiryDateText);

All 4 give the same result?

This code however

            DateTime? expiryDate5 = new DateTime?();

It is correct to for it to have a value of null, because new will return the default value, since it's a nullable type, that's null

so what are you saying lol. obviously new will return the default. i was just wonder why a and b always gives a null regardless whether or not the text read from the text box into the string var has or has not a value. according the inline if its true in a (there is a value read as i pointed out) it should not assign the default via new which would make it null, but parse the date from the text and use the value. same for b just in reverse obviously since i switched it around.

c i just added to see if the inline would go as it would go and assign the parse and well d just for the sake of it.

 

[Necuno]

That's just silly. Whether you use inline evaluation, and the ?: operator, or a lengthy, nested if else statement, the compiler will still spit out the same IL code. Don't blame the language or compiler because the developers have a poor understanding of it.

please feel free to point out where i blame it.

Oh, by the way, you should NEVER NEVER use DateTime.Parse() Always use Date.ParseExact() or even better, Date.TryParseExact, to prevent the exception from being thrown:

why ? it will always be a correct date format till kingdom come as per control i'm using; there will never be a parse exception nor a value passed which can't be parsed.

 

[Necuno]

ok ill re do the simple lines tomorrow out of the monstrious app and in a simple new win form. thanks. evedently something kaputed something

 

[Saajid]

please feel free to point out where i blame it.

My comment was directed at Rouxenator... not you.

why ? it will always be a correct date format till kingdom come as per control i'm using; there will never be a parse exception nor a value passed which can't be parsed.

Good for you. If the control that you are using is so solid, then why aren't you working with DateTime instances directly, instead of trying to parse plaintext?

My guess is that the plaintext you are trying to parse is coming from user input, or some other external source.

Are the date strings guaranteed to always be unambiguous?

For e.g.
11 September 2009 is unambiguous.
11/09/09 is VERY ambiguous. Which digit-pair represents the year, month and day, respectively? Does DateTime.Parse() agree with you? How do you know? Is it using the CurrentCulture of your own computer (e.g. ZA)? what if you move your application to another machine with a different current culture (US). Will DateTime.Parse() still behave the same?

NO!

Just Google DateTime.Parse() - http://www.google.com/search?q=datetime.parse and read for yourself.

 

[Necuno]

My comment was directed at Rouxenator... not you.

saw that, but didn't re-edit my post.

Good for you. If the control that you are using is so solid, then why aren't you working with DateTime instances directly, instead of trying to parse plaintext?

My guess is that the plaintext you are trying to parse is coming from user input, or some other external source.

Are the date strings guaranteed to always be unambiguous?

For e.g.
11 September 2009 is unamiguous.
11/09/09 is VERY ambiguous. Which digit-pair represents the year, month and day, respectively? Does DateTime.Parse() agree with you? How do you know? Is it using the CurrentCulture of your own computer (e.g. ZA)? what if you move your application to another machine with a different current culture (US). Will DateTime.Parse() still behave the same?

NO!

this is asp.net and not winforms which will have the control need to read somewhere along the lines as text and convert it to a datetime var. its always recieved as dd/mm/yyyy as the format is hard set to a set standard all dates use internally and not as the above yy/mm/dd. the date itself is not required so its either null or not null. when its not null i need to know the date obviously which is read via shared datetime? var...

 

[Rouxenator]

Lamda expression are helpful yes - if you are only going to use the function once - else create a delegate for it.

Inline if statements are like working in MS Excel - its lame. I use them sometimes for quick prototypes but in production systems where other developers need to perform maintenance on the code it is best to make it as easy to follow as possible.

 

[Necuno]

Lamda expression are helpful yes - if you are only going to use the function once - else create a delegate for it.

Inline if statements are like working in MS Excel - its lame. I use them sometimes for quick prototypes but in production systems where other developers need to perform maintenance on the code it is best to make it as easy to follow as possible.

so you would rather write the following

//don't proccess non datarows
if(e.Row.RowType != DataControlRowType.DataRow)
{
     return;
}

in stead of

//don't proccess non datarows
if(e.Row.RowType != DataControlRowType.DataRow) return;

or

string name = null;

if(dbRdr.IsNull(1))
{
    name = "";
}
else
{
    name = Convert.ToString(dbRdr["Name"]);
}

in stead of

var  name = (dbRdr.IsNull(1)) ? "" : Convert.ToString(dbRdr["Name"]);

i don't see a problem with inline when its used properly without it looking like a troll's ass. same with lambda expressions.

 

[Rouxenator]

In my line of work code readability is very important, so yes - we go with the exploded view for statements.

 

[Necuno]

In my line of work code readability is very important, so yes - we go with the exploded view for statements.

i would suggest a good eye doctor or decent intellegence check

seriously both of my examples there should not be reading issues or you should go and ask your money back at whom ever you trained with imho.

 

[Necuno]

...how hard is it to understand this ? (the norm where i might use lambda anyways)

var person = persons.SelectSingle(p => p.IDNumber == currentID);

 

[Necuno]

Inline if can be evil, I will agree, but this is a great situation to use one, anthing more and I'm on your side.

result = checkIfNull : YesItIsReturnDefault ? NoItIsntReturnValue;

The problem is a lot of people will start to get confused quickly:

[b]Is this[/b]
result = condition1 == condition2 ? result : 0;
[b]Evaluated like this[/b]
result = (condition1 == condition2) ? result : 0;
[b]or like this?[/b]
result = condition1 == (condition2 ? result : 0);
[b]eerrggg!![/b]

Here's an interesting situation:

decimal result = (decimal)(condition ? value : 0);        [b]// InvalidCastException[/b]
decimal result = condition ? (decimal)value : (decimal)0; [b]// works fine[/b]

exactly. i'd normally also use some inline where it is also a simple boolean and a return. ex if(NotExpected) return; instead of the whole bracket thing, but then i also comment why it is so just above it.

 

[Necuno]

lol...

 

[Rouxenator]

Necuno, you don't by any chance work in a development team with 5 other developers and 3 maintenance developers in another division of the same company ? Is you average turn around time on change requests or support tickets less than 3 hours ?

Anyone can read inline statements, but for some - especially junior developers - it is not the quickest code to debug through.

Your attitude towards this kinda reminds me of last weeks XKCD : http://www.xkcd.org/664/