Fredrik Normén

# re: Avoid "else" as much as possible, use "?:" instead

I use the ?: syntax quite often although the readability decrease with complexity..

One example where I use this is:

string res = obj.IsNull ? "" : obj.SomeProperty;

I think that the ?: syntax is really neat, but I don't think it is more readable when the true/false result parts gets a little bit more heavy..

# re: Avoid "else" as much as possible, use "?:" instead

Well, in that case I guess I would write "return expression;". ;-)

If there is a simple if statement with two different outputs like in your example, I use "?:", but if there is a more "advanced" if statement, I use if and else.

But what about the coalesce operator?

string firstname = null;

string lastname = "Söderström";

string name = firstname ?? lastname; // Returns lastname since firstname is null

/Mikael Söderström

# re: Avoid "else" as much as possible, use "?:" instead

When I studied at the university, my C++ teacher called the ?-operator "hacker if" so I've been brought up not to use it. In certain situations I suppose it's convenient though.

I haven't tested this or anything, but surely the use of if-else or ?: must result in the same IL?

# re: Avoid "else" as much as possible, use "?:" instead

I agree as well, if it gets to complex you should avoid the ? : construction and use if else for readabillity.

For a simple test it's nicer to use the ? : construction.

# re: Avoid "else" as much as possible, use "?:" instead

I like the ? too... And i guess it's very usefull when not having to advance operations.

Like Söderström says:

What do you think about?

if(foo == null)

  return (new Foo());

and

return (foo ?? new Foo());

# re: Avoid "else" as much as possible, use "?:" instead

It depends upon complexity. For very simple things I'll use the short form, but for anything more complex I'll use the full form. And by "simple things" I also mean line length; it's all about readability to me and considering who might read my code later on.

# re: Avoid "else" as much as possible, use "?:" instead

I simply use ?: when there is a choice to make (returns and assignments, sometimes nested). If actions need to be performed based on a condition, the if-else construct makes more sense. As for readibility, after using both constructs for many years, I find them both equal. I hate verbosity.

# re: Avoid "else" as much as possible, use "?:" instead

I agree with Dave and Mike... it really depends on the project and context. In places where the ternary may be overlooked, I use else. Otherwise I prefer ternary.

# re: Avoid "else" as much as possible, use "?:" instead

I like it, but its definitely stigmatized.  Kind of feel like I'm smoking in a public restaurant whenever I drop it into some production code.

# re: Avoid "else" as much as possible, use "?:" instead

Please. Its the best way to handle sending items into methods.

dosomething(

something1

something2 == null ? 7: 14,

something3 == 3 ? 21: 28);

# re: Avoid "else" as much as possible, use "?:" instead

Perhaps I can refine your point a little more, Fredrik: Try to avoid having a situation where you need an else. Sometimes, for simple logic, you need an else condition and it should be very simple such that an ?: operator makes sense.

If you (anyone, all of us) have a big if() and then a big else condition, your design may smell a little and you should reconsider some of your design choices such that you minimize the number of conditional branches. This increases cyclomatic complexity and decreases your ability to test this functionality effectively.

# re: Avoid "else" as much as possible, use "?:" instead

I think that multiple return statements is generally BAD and the use of ? is therefore a better alternative in that specific case. When multiple if/else statements is needed the ? operator can actually improve readabillity in the code by reducing the number of sourcelines.

# re: Avoid "else" as much as possible, use "?:" instead

If you're doing returns, I prefer the following:

if (expression)

 return val1;

return val2;

And, if the expression is a simple validation, I'll put the return on the same line:

public string WrappedToUpper(string s) {

 if (string.IsNullOrEmpty(s)) return string.empty;

 return s.ToUppper();

}

Horses for courses =)

# re: Avoid "else" as much as possible, use "?:" instead

Personally I think we should use ? : only when required, which is when you need a simple expression in place, for things like parameters into other methods etc. But even then I suppose it could be argued it's better to go into an intermediary value.

To me the ? : gets unwieldy very quickly so I rarely use it. In most situations it's just cleaner to have the written out syntax which is easier on the (my) mind to parse.

# re: Avoid "else" as much as possible, use "?:" instead

well, i do use ?: a lot in my code...but i do also lots of lambda expressions. why? simply because I enjoy compact code. Most of the time, I think it does not decrease readibility, but when I show the code to newcomers, I've noticed that some do have a  hard time reading it...

# re: Avoid "else" as much as possible, use "?:" instead

It is hard to tell, since you omitted the title of the book, what the author intended with her advice, but since you mention that it is about OOP I guess that it isn’t about brevity. If you use “else” chances are you, or your fellow developers, will be more prone to introduce more code in the if-else-statements or even add more conditionals to them when maintaining the code. The use of ?: then serves as a reminder to avoid if-else chaining.

# re: Avoid "else" as much as possible, use "?:" instead

What code block do you like more?

First:

           IDictionary oCultureCache = s_oResourceCache[p_sCulture] as IDictionary;

           if (oCultureCache == null)

           {

               oCultureCache = new Dictionary<string, Dictionary<string, string>>();

               s_oResourceCache.Add(p_sCulture, oCultureCache);

           }

           IDictionary oClassCache = oCultureCache[p_sClassName] as IDictionary;

           if (oClassCache == null)

           {

               oClassCache = new Dictionary<string, string>();

               oCultureCache.Add(p_sClassName, oClassCache);

           }

           oClassCache[p_sKey] = p_sValue;

Or second:

               IDictionary oCultureCache = (s_oResourceCache[p_sCulture] as IDictionary) ??

                                           (IDictionary)(s_oResourceCache[p_sCulture] =

                                                          new Dictionary<string, Dictionary<string, string>>());

               IDictionary oClassCache = (oCultureCache[p_sClassName] as IDictionary) ??

                                         (IDictionary)

                                         (oCultureCache[p_sClassName] = new Dictionary<string, string>());

               oClassCache[p_sKey] = p_sValue;

# re: Avoid "else" as much as possible, use "?:" instead

I dissagre.

Use of ?: is for smal things like converting bool to on / off string and similar

if

{}

else   is for logic , and is by fare more readable ,

# re: Avoid "else" as much as possible, use "?:" instead

Thank you, Fredrik.

But I have some additional questions.

>Regarding to the .Net naming Guidelines, no prefix should be used ;)

Unfortunately, the company, for which this code was written, uses other guidelines.

BTW, where can I find .Net naming Guidelines you're talking about?

>I should use the ContainsKey instead of using “as” and compare the object with null to see if I succeed to cast or the Cache has the value.

What if _resourceCache contains a key we are looking for, but a corresponding value is not Dictionary<string, Dictionary<string, string>> ?

And what are advantages of ContainsKey?

# re: Avoid "else" as much as possible, use "?:" instead

The number of lines of code is completly irrelevant in this case, since both examples will be compiled to the same MSIL-code. I prefere the if-way to do it, but there are a few cases when I use the ?: instead. It basically depends on the situation.

When writing ugly-as code with conditions in the presentationlayer (ie in an <%#eval()%> statement, I think you're bound to the ?: (or of cource moving logic to codebehind where it belongs)