CODEWITHSUNDEEP
c#
Cristian Libardo
Cristian Libardo

Reputation: 9258

TryParse: What is more readable?

Out style:

bool result;
if(something.TryParse(val, out result))
{
    DoSomething(result);
}

Nullable style:

bool? result = something.TryParse2(val);
if(result.HasValue)
{
    DoSomething(result.Value);
}

Upvotes: 0

Views: 790

Answers (8)

Jay Bazuzi
Jay Bazuzi

Reputation: 46506

I find both examples to be clunky.

I'd choose the TryParse because it's an idiom that already exists in the .NET Framework.

Upvotes: 0

Hallgrim
Hallgrim

Reputation: 15513

TryParse(val, out result) is a idiom established by the .NET framework in int.TryParse, DateTime.TryParse, etc. It is likely that people that read the code will be familiar with this idiom, so you should stick to it, unless you find a very good reason not to.

Upvotes: 9

Robert Rossney
Robert Rossney

Reputation: 96722

I don't mean to be unkind. But when you propose a change to a well-established idiom, it undermines confidence if your sample code isn't right.

Your first example should either be:

something result;
if (something.TryParse(val, out result))
{
   DoSomething(result);
}

or:

bool result;
if (bool.TryParse(value, out result))
{
    DoSomething(result);
}

Your second example should either be:

Nullable<something> result = something.TryParse2(val);
if(result.HasValue)
{
    DoSomething(result.Value);
}

or:

bool? result = bool.TryParse2(val);
if (result.HasValue)
{
   DoSomething(result);
}

If I were going to implement an extension method for each value type that did what your TryParse2 seems to do, I wouldn't call it TryParse2. Right now, if a method's name begins with Try, we expect it to return a bool indicating whether or not it succeeded or failed. Creating this new method creates a world where that expectation is no longer valid. And before you dismiss this, think about what was going through your mind when you wrote example code that didn't work, and why you were so sure that result needed to be a bool.

The other thing about your proposal is that it seems to be trying to solve the wrong problem. If I found myself writing a lot of TryParse blocks, the first question I'd ask isn't "How can I do this in fewer lines of code?" I'd ask, "Why do I have parsing code scattered throughout my application?" My first instinct would be to come up with a higher level of abstraction for what I'm really trying to do when I'm duplicating all of that TryParse code.

Upvotes: 4

JaredPar
JaredPar

Reputation: 754725

I prefer the second example because it's a more type inference friendly style of programming. Having an out parameter prevents a developer from using type inference for a particular call. 


var result = Int32.TryParse("123");

Upvotes: 0

Schotime
Schotime

Reputation: 15977

I have seen the out variable syntax used in many applications.

Personally I like it too.

Upvotes: 0

REA_ANDREW
REA_ANDREW

Reputation: 10764

A nullable type has a Value property which is not nullable of the same type. This is where you do not need to convert a nullable type but rather use the value of the nullable type.

Upvotes: 0

Vinko Vrsalovic
Vinko Vrsalovic

Reputation: 340241

I think out style is more readable in general. People are less familiar with nullable types (just check the amount of questions about them here), and they'll be even less familiar with a TryParse2 which does not exist in the standard library (or however it's technically called in .NET).

Upvotes: 2

REA_ANDREW
REA_ANDREW

Reputation: 10764

I would probably use the second example. Although I see both as perfectly acceptable.

Upvotes: 0

Related Questions