Easy Syntax Question

[Terry McNamee]

return arr.Length == 0 ? null : arr[item].ToString();



Can anyone tell me what this syntax means?

Does it basically mean if arr.Length is equal to 0 then return null, else
return the item in the array ??

 

[Bruce Wood]

Yes. It is equivalent to:

if (arr.Length == 0)
{
return null;
}
else
{
return arr[item].ToString();
}

BTW, I hate the "ternary" operator. I hated it in C, I hated it in C++,
and now I hate it in C#, too. There's only one place in C# where you
absolutely can't do without it, and that's when chaining constructor
calls, where you're not allowed to insert "if" statements:

MyClass(string foo) : base(foo == null : "" ? foo)

Otherwise, it's just a throwback to the days of "look how much code I
can stuff onto one line". Ugly and difficult to maintain, IMHO.

 

[Jon Skeet [C# MVP]]

return arr.Length == 0 ? null : arr[item].ToString();

Can anyone tell me what this syntax means?

Does it basically mean if arr.Length is equal to 0 then return null, else
return the item in the array ??

Exactly. It's a conditional operator. Basically, the condition
(leftmost operand) is evaluated, and if it evaluates to true, the
middle operand is evaluated and is the result of the expression.
Otherwise, the rightmost operand is evaluated and is the result of the
expression.

 

[Nicholas Paldino [.NET/C# MVP]]

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

Hope this helps.

 

[C# Learner]

[the ternary operator]

Otherwise, it's just a throwback to the days of "look how much code I
can stuff onto one line". Ugly and difficult to maintain, IMHO.

While it's certainly possible to abuse it (as is the case with some other
language features), there are situations where it helps make the code nicer
and more readable, IMO.

For example, I find

string s = foo ? "foo" : "not foo";

much nicer and more readable than

string s;
if (foo) {
s = "foo";
} else {
s = "not foo";
}

Using the 'if .. else' construct here is overkill in comparison, IMO.

 

[Terry McNamee]

Thanks Guys.

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

return arr.Length == 0 ? null : arr[item].ToString();



Can anyone tell me what this syntax means?

Does it basically mean if arr.Length is equal to 0 then return null, else
return the item in the array ??

 

[Jonathan Allen]

While it's certainly possible to abuse it

My favorite example from real life:
bool var = (a != null ) ? true : false;

if (foo) {
s = "foo";
} else {
s = "not foo";
}

That can be cut down quite a bit using the If-Then-Else pattern from
FORTRAN/BASIC. Still, not quite as good as it could be.

if (foo) s = "foo"; else s = "not foo";

--
Jonathan Allen

[the ternary operator]

Otherwise, it's just a throwback to the days of "look how much code I
can stuff onto one line". Ugly and difficult to maintain, IMHO.

While it's certainly possible to abuse it (as is the case with some other
language features), there are situations where it helps make the code
nicer
and more readable, IMO.

For example, I find

string s = foo ? "foo" : "not foo";

much nicer and more readable than

string s;
if (foo) {
s = "foo";
} else {
s = "not foo";
}

Using the 'if .. else' construct here is overkill in comparison, IMO.

 

[Bill Butler]

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

I'll Top that :^)
return ((arr == null || arr.Length <= item) ? null : arr[item].ToString());

That way we don't index outside the Array. (unless you like exceptions)

Bill

 

[C# Learner]

if (foo) s = "foo"; else s = "not foo";

Still, to go with my example it'd have to be:

string s;
if (foo) s = "foo"; else s = "not foo";

I'd take

string s = foo ? "foo" : "not foo";

over that anytime. It's clearer and nicer (IMO), and it doesn't
require you to break your coding style temporarily.

 

[Bruce Wood]

My problem with the ternary operator has always been a result of my
work environment: I've always worked in multi-language shops. When
you're working shoulder-to-shoulder with COBOL programmers and VB
programmers, you're better off writing

if (foo)
{
s = "foo";
}
else
{
s = "not foo";
}

even though it's much wordier. That way, when the guy next to you has
to take over maintaining the C code for a week while you're on
vacation, he has a much easier time of it, even if he doesn't know much
C.

If you work in a C#-only (or C-only or C++-only) shop, then I see no
problem with the ternary operator. In my work environment, however,
it's just one more mysterious C-ism that the other poor sods around me
have to cope with, so I avoid it wherever I can.

 

[Guest]

bool var = (a != null ) ? true : false;

Note that the ternary operator isn't even necessary there - (a != null)
evaluates to a bool anyways.

bool var = (a != null); // functionally equivelant without the extra operation

While it's certainly possible to abuse it

My favorite example from real life:
bool var = (a != null ) ? true : false;

if (foo) {
s = "foo";
} else {
s = "not foo";
}

That can be cut down quite a bit using the If-Then-Else pattern from
FORTRAN/BASIC. Still, not quite as good as it could be.

if (foo) s = "foo"; else s = "not foo";

--
Jonathan Allen

[the ternary operator]

Otherwise, it's just a throwback to the days of "look how much code I
can stuff onto one line". Ugly and difficult to maintain, IMHO.

While it's certainly possible to abuse it (as is the case with some other
language features), there are situations where it helps make the code
nicer
and more readable, IMO.

For example, I find

string s = foo ? "foo" : "not foo";

much nicer and more readable than

string s;
if (foo) {
s = "foo";
} else {
s = "not foo";
}

Using the 'if .. else' construct here is overkill in comparison, IMO.

 

[Guest]

My bad -- that <= does check the lower bound.
Spoke too soon!

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

I'll Top that :^)
return ((arr == null || arr.Length <= item) ? null : arr[item].ToString());

That way we don't index outside the Array. (unless you like exceptions)

Bill

 

[Guest]

You should probably check the lower bound of the array then too -- (item > -1)

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

I'll Top that :^)
return ((arr == null || arr.Length <= item) ? null : arr[item].ToString());

That way we don't index outside the Array. (unless you like exceptions)

Bill

 

[Guest]

No it doesn't! You need to check upper and lower bounds --

(item > -1 && item < arr.Length)

My bad -- that <= does check the lower bound.
Spoke too soon!

Terry,

For the most part, yes. However, to be correct, it should be:

return ((arr == null || arr.Length == 0) ? null : arr[item].ToString());

This assumes that arr might be null.

I'll Top that :^)
return ((arr == null || arr.Length <= item) ? null : arr[item].ToString());

That way we don't index outside the Array. (unless you like exceptions)

Bill

 

[Bruce Wood]

Yes, I think that was his point.

 

[Jon Skeet [C# MVP]]

If you work in a C#-only (or C-only or C++-only) shop, then I see no
problem with the ternary operator. In my work environment, however,
it's just one more mysterious C-ism that the other poor sods around me
have to cope with, so I avoid it wherever I can.

My problem with that approach is - how far do you take it? Do you
assume that they don't know that && and || are shortcircuiting, too? Do
you assume they don't know default access modifiers? Do you assume they
don't know default variable values? What about the using/lock
statements, which will confuse C/C++ programmers if they don't know C#?
I think sooner or later you have to assume that your co-workers have a
working knowledge of the language.

My view is that if something is somewhat onerous to remember (like
exact precedence rules) then it helps to make it more explicit. If it's
easy to foul up even with experience (like using single statement "if"s
with no braces) then it helps to make it more explicit.

If it's a simple language construct which is easy to explain once and
then ask people to remember, I don't see what's wrong with it. Of
course, you have to also have an environment where people are happy to
ask if they don't understand something, and have enough people with
good knowledge (or the ability to find something in a language spec) to
help them if they get stuck.

As a side issue, what does the VB code in your work environment look
like? There's so much *language* to learn in VB in the first place, if
everything has to be understandable to everyone, I don't see how it can
work...

 

[Bruce Wood]

Good points, all. I guess this is just baggage from other programming
jobs, back when I was programming in C and everything was relatively
straightforward. Back then I avoided the ternary operator, assignments
inside conditions, and other unnecessary C-isms out of respect for the
other programmers around me.

Now that, as you point out, there are far bigger fish to fry in C#, my
prejudice against the ternary operator is probably outdated. After all
those years trying to write clearer code, though, it just looks ugly to
me, so I guess it's devolved into an aesthetics thing.