Today I had an interesting chat with one of my colleagues. He sent me this link talking about the new improved C# 6.0 features.
Quite interesting stuff. He had one special thing to discuss about and pointed to these lines code. It is about the null-conditional operator, certainly:
My buddy asked me what do I think about it. Isn’t that great reduction of code size?
Let’s consider that code.
- What is my expectation when calling that function?
- What do I want to accomplish, what do I need to make this code robust?
- How do I make my infrastructure of calling methods and retrieving information unified to all my code?
Yes
this is not a comprehensive example. It’s a small piece of code that should show how we can reduce logic and therefore have less lines of code in the first place.
No
certainly I don’t want to have extra lines of code to check if the return value is null. Why doesn’t this method just simply returns an empty list instead of null?
If this would be the case, there is actual no need to use the null-conditional operator at all. We can happily return the count without any problems of checking. Generelly applied to as a rule we may not even think about return values. (This area is quite some kind of different when we’re talking about algorithims that must be highly optimized).
Actually there is nothing against the usage of the null-conditional operator when it is simple and straight. But what about misuse? Not only shorten the code but thinking about this operator as an ever healing cure.
As described in a former post – What’s wrong with that: I am not that good in naming classes – , I more often see misuses.
Have a look here:
This is a pretty good example of avoiding taking responsibility of the written code. Let’s summarize the usages.
- _excelApplicationManager?: Actually we use dependency injection. This is a service that will be created by Windsor Castle and injected into that class. It will be stored in an readonly field variable. When we really need to do this check, we have a pretty huge problem – then there is something really problematic in our environment. This one is really absolutely senseless and will confuse the reader.
- .Application?: So this may be a valid one? Why not write more readable code by another property called “HasApplication” that this service provides? Especially the code after anyway has to deal with the results. So just returning null value here will lead to not evaluate the full line of code but what then? I prefer to check the necessary variables directly and throw descriptive exceptions that show why the program misbehaves. In this case, there is nothing beside a null exception that will come up somewhen later in code. And then I don’t know what the reason was.
- .ActiveWorkbook?: The same applies here. When the activeworkbook is not specified the program has to communicate that taking action is impossible without that prerequisite.
- .Excel: There is no operator anymore. Why? Cannot be null? Why going back to Excel instance? A lt of question raises here.
- .Sheets(chartGraphic.ShareRange.AlternativeText): I did write about that problems in the other post, but certainly also here we need to act more straight forward. If there is no Sheet with that name it will fail ungracefully.
Again my suggestion is to take responsibility. Every single line of code has a meaning. Shorten code is great when it simplifies, not on cost of readability. Be clear about how to handle null values, either within a method or when returning information after calling a method.
Then this operator will not be overused, and not be used in wrong places.