I had an idea about creating a bool isNull that can be used pretty much ambiguously wherever needed. The original idea was as follows (pseudo-code only):
bool isNull(var test)
{
if (test == null || DBNull || string.Empty)
return true;
else
return false;
}
But this doesn't work, as var is not recognised here. Instead, it appears to be assumed that var refers to a type... well I, of course, don't have a type for var!
What do I do to get around this? Or, perhaps the question I should be asking, Is this a good idea at all?
Why don't you use object ?
bool isNull(object test)
{
if (test == null || test == DBNull.Value)
return true;
else
return false;
}
For strings, I would use string.IsNullOrEmpty method.For other types, especially when you are dealing with databases this function can be useful.
Your code isn't working because var will be resolved at compile-time.
You could use object or dynamic as type. dynamic will be resolved at run-time
Related
a ?? b
If a is not null => returns a.
Else (a is null) => returns b.
I want to simulate something like its inverse (AFAIK there is no operator to do this):
If a is null => return a.
Else (a is not null) => returns b.
The idea is that b would be the result of a function that receives a and needs to avoid null parameters. Like this: a XX fn(a) where XX would be the operator (if it exists).
My only two variants are:
a == null ? a : fn(a)
a == null ? null : fn(a)
Is there any way to simplify this code?
Not sure exactly what you're trying to accomplish? Something like this?
TResult NullFn<TParam, TResult>(TParam a, Func<TParam, TResult> method)
{
if(a == null) return null;
return method(a);
}
...
var result = NullFn(a, a => fn(a))
But the best solution IMHO would be to just have fn return null if it is passed a null value.
EDIT:
The method at the top is only an example. You might want to use something like this in a situation where you've got a LOT of the same operation over and over again in a specific area and you can't change fn because it would make is easier to focus on the rest of the code and there's a chance you might want to alter the null-handling behavior for all your operations at once in the future. (I'm assuming that is the case because you're asking in the first place.) But I wouldn't use this across an entire application because it isn't clear what's happening if you don't have the NullFn function right in front of you.
Whats wrong with simple condition?
if (a != null) b = fn(a);
Another option - add a condition to your method:
public B fn(A a)
{
if (a == null)
return null;
return new B();
}
Personally I would prefer
(a != null) ? fn(a) : null
because I think it makes the intention more obvious, but I can not think of a way to simplify that much. You could use an extension method if you like.
a.CallIfNotNull(fn)
with the following extension method
internal static T CallIfNotNull<T>(this T value, Func<T, T> function)
where T : class
{
return (value != null) ? function(value) : null;
}
Not really better but probably less error prone and easier to type given IntelliSense.
(Is assumed the function returns a value of the same type as the argument as the question suggests.)
If you have T a; and T fn(T a); using the same user-defined type T, then you can write a && fn(a) and it will expand to T.False(a) ? a : T.&(a, fn(a)).
You've answered your own question with the ?: implementations at the bottom.
The only improvement i would suggest is to wrap the functionality in a method that makes it cleaner and less error prone to do.
object SafeB(object a)
{
return a==null ? a : b(a);
}
The compiler will probably inline this so you won't lose performance.
You may even be able to implement it as an extension method of the class that provides b so that it becomes an even more integrated solution.
I've ran into an issue where code classes outside of my control use strings that are null so when they become referenced for example, "string.Length", causes an error. Rather than write a check for the possible 100 fields on average, with nested classes, I thought maybe I could create something easier. I had an idea...
If you've done any research into copying objects PropertyCopy, along with a few others, is an extremely common find. I currently use the class mentioned above. I was wondering if it could be modified to simply go:
if stringPropertyValue is null then set stringPropertyValue equal to string.Empty.
My understanding is limited. I've been doing research to solve my issue but no real good ideas. Can my idea work? Is there a better way? How would it be done if it could?
Update:
Based on a response below I have created this class which I am currently going to use.
public static void DenullifyStringsToEmpty<T>(this T instance)
{
//handle properties
foreach (var filteredProperties in instance.GetType().GetProperties().Where(p =>
(p.PropertyType.IsClass || p.PropertyType.IsInterface || p.PropertyType == typeof(string))))
{
if (filteredProperties.PropertyType == typeof(string))
{
if (filteredProperties.GetValue(instance, null) == null)
{
filteredProperties.SetValue(instance, string.Empty, null);
}
}
else
{
filteredProperties.GetValue(instance, null).DenullifyStringsToEmpty();
}
}
//handle fields
foreach (var filteredFields in instance.GetType().GetFields().Where(f =>
(f.FieldType.IsClass || f.FieldType.IsInterface || f.FieldType == typeof(string))))
{
if (filteredFields.FieldType == typeof(string))
{
if (filteredFields.GetValue(instance) == null)
{
filteredFields.SetValue(instance, string.Empty);
}
}
else
{
filteredFields.GetValue(instance).DenullifyStringsToEmpty();
}
}
}
I know that reflection can be heavy and until we have an issue I think this solution will work great. This is an extension (thanks to the comments below).
Thanks for the input.
Couldn't you just create a simple extension method?
public static string NullToEmpty(this string possibleNullString)
{
return possibleNullString ?? string.Empty;
}
Use this, when accessing the string properties of that third party classes, e.g.:
var length = instanceOfThirdPartyClass.StringProperty.NullToEmpty().Length;
Update:
Now that I understand what you want ;-)
Have a look at this:
public static void DenullStringProperties<T>(this T instance)
{
foreach(var propertyInfo in instance.GetType().GetProperties().
Where(p => p.PropertyType == typeof(string))
{
var value = propertyInfo.GetValue(instance, null);
if(value == null)
value = string.Empty;
propertyInfo.SetValue(instance, value, null);
}
}
You could call it like this:
instanceOfThirdPartyClass.DenullStringProperties();
But I still think you should go with the first approach, because I really don't see a reason to do such heavy lifting during runtime (reflection isn't cheap), just because you are lazy about typing during development :) Additionally, you can't be sure that the properties will stay non null after you have called DenullStringProperties (multi-threading, calls to methods of the object, ...). The first approach checks for null and handles it just as it is needed.
This question already has answers here:
Best and fastest way to check if an object is null [duplicate]
(6 answers)
Closed 9 years ago.
What is the most efficient way to check for null references on objects? I have seen various code samples that have different ways of checking so of the following which is the most efficient or the one that it is considered best practice to use?
Object.ReferenceEquals(item, null)
item == null
item != null
Object.Equals(item, null)
thanks
Object.ReferenceEquals(item, null) compare references and equals to item == null.
Object.Equals(item, null) compare references for reference types and bitwise for value types, but in reflector it's equal to (item == null) || ((item != null && null != null) && item.Equals(null)).
item != null code not always equals to !(item == null), but of course result should be equal.
item == null code not equals to null == item, it's similar to typeof(item).Equals(object) and object.Equals(typeof(item)) method calls.
It differ because you can override !=, ==, Equals.
Use methods with known implementation, null == item is better to code, but harder to read.
Object.ReferenceEquals(null, item) may be faster or not.
P.S. use string.IsNullOrEmpty(item) too
For comparing to null, I'd use == or != always, because for null it should always give the same result as ReferenceEquals and Equals anyway (so no need for the extra code).
Edit: It's true that == could be overridden to give a wrong result for null (i.e., true) but that means the override is buggy. To make the code readable I would stick with == and !=.
Updated answer
As of C# 7.0 is you can use:
item is null
should be the simplest and most foolproof way. It's same as ReferenceEquals check.
Old answer:
1)
Object.ReferenceEquals(item, null)
This is a good way. Not as concise as I would love, but still great and tells u the intent exactly.
2)
item == null
item != null
There is nothing wrong with this (which is the most elegant) if you are sure == and subsequently != is overloaded correctly. Its easy to write (overload) bad equality operators (and often done). But the real trouble is when you are trying to overload == operator in a class (lets say of value semantic). You cant use == for null checks inside == overloading function of the class since that will cause an infinite recursion. To have one consistent style, I rely on something else.
3)
Object.Equals(item, null)
Again it internally does a ReferenceEquals so there is not much point, but if it semantically makes more sense to you, then go with this.
4)
My approach is to do
(object)item == null
upon which I'm relying on object's own equality operator which can't go wrong. Not so readable so I just wrap in a custom extension method and an overload:
public static bool IsNull<T>(this T obj) where T : class
{
return (object)obj == null;
}
public static bool IsNull<T>(this T? obj) where T : struct
{
return !obj.HasValue;
}
It makes more sense since I will need to check against DBNulls too often. So now I have one consistent style all over!
public static bool IsNull<T>(this T obj) where T : class
{
return (object)obj == null || obj == DBNull.Value;
}
(Do not take off the (object) casting as that's what will prevent infinite recursion when overloading == as stated before)
Additionally the constraint prevents IsNull on value types. Now its as sweet as calling
object obj = new object();
Guid? guid = null;
bool b = obj.IsNull(); // false
b = guid.IsNull(); // true
2.IsNull(); // error
I also have found (object)item == null is very very very slightly faster than Object.ReferenceEquals(item, null) or object.Equals(,) for that matter, but only if it matters (I'm currently working on something where I've to micro-optimize everything!).
To see a complete guide on implementing equality checks, see What is "Best Practice" For Comparing Two Instances of a Reference Type?
As an extra, don't forget code contracts in .NET 4.0!
System.Diagnostics.Contracts.Contract.Requires(item != null);
Which is not only nice and clear, but allows compile time checking. See Code Contracts in msdn.
ReferenceEquals is equivalent to (object)o1==(object)o2. It may be faster than o1==o2 if the equality operator is overloaded. Object.Equals is probably a bit slower.
The difference between == and != isn't performance, but how your program should look like. They can be a bit slower if the == and != operator are overloaded.
But I don't think the performance difference between them matters at all. I'd choose the one that's easiest to read. And that's usually == or !=.
If I throw an exception I usually use == as in:
if(o == null)
throw new ...;
If null results in a no-op then usually != is appropriate
if(x != null)
{
...
}
I always use
item != null
but this is harder to read than
item == null
Object.ReferenceEquals is used to check whether two objects are the same instance.
First 2 are the same effectively.
The last however does not only do a reference check, and should not be used for null checking.
if (Request.QueryString["UseGroups"] != null)
{
if (Request.QueryString["UseGroups"] == "True")
{
report.IncludeGroupFiltering = true;
}
else
{
report.IncludeGroupFiltering = false;
}
}
else
{
report.IncludeGroupFiltering = false;
}
Simply a single check:
report.IncludeGroupFiltering = Request.QueryString["UseGroups"] == "True";
There's no need to evaluate Request.QueryString["UseGroups"] twice - it can only be equal to "True" if it's non-null, and the comparison will work perfectly well (and return false) if it is null.
Any solutions still doing two operations are over-complicating matters :)
report.IncludeGroupFiltering = Request.QueryString["UseGroups"] == "True"
report.IncludeGroupFiltering = Request.QueryString["UseGroups"] == "True";
I think Request.QueryString["UseGroups"] == "True" and "True" is a string only , it does not behave like bool.
So,
you can write in a line
report.IncludeGroupFiltering = string.IsNullOrEmpty(Request.QueryString["UseGroups"])?
false : (Request.QueryString["UseGroups"] == "True");
report.IncludeGroupFiltering = "True" == Request.QueryString["UseGroups"];
Factor out the Request.QueryString["UseGroups"] part to make it clear you want to refer to the same thing, and then it becomes:
string useGroups = Request.QueryString["UseGroups"];
report.IncludeGroupFiltering = (useGroups != null) && (useGroups == "True");
report.IncludeGroupFiltering = (Request.QueryString["UseGroups"] != null)
&& (Request.QueryString["UseGroups"] == "True");
You're doing it basically the way I would. Just remove the redundant inner else:
if(Request.QueryString["USeGroups"] != null)
{
if(Request.QueryString["UseGroups"] == "True")
report.IncludeGroupFiltering = true;
}
else report.IncludeGroupFiltering = false;
Maybe this:
report.IncludeGroupFiltering = false;
if (Request.QueryString["UseGroups"] == "True")
report.IncludeGroupFiltering = true;
What about using TryParse:
bool includeGroupFiltering;
bool throwaway = Boolean.TryParse(Request.QueryString["UseGroups"], out includeGroupFiltering);
report.IncludeGroupFiltering = includeGroupFiltering;
This is how I do this sort of code:
report.IncludeGroupFiltering = false;
if (Request.QueryString["UseGroups"] != null &&
Request.QueryString["UseGroups"] == "True" //note that I am not a C# expert - this line /may/ throw an exception if it is indeed null.
{
report.IncludeGroupFiltering = true;
}
report.IncludeGroupFiltering = ShouldIncludeGroupFiltering(Request.QueryString["UseGroups"])
private boolean ShouldIncludeGroupFiltering(String queryString) {
return ("True" == queryString)
}
String constants are immutable and atomized, they are also reference objects. However the result of Request.QueryString["UserGroups"] is a string reference (or a reference to an object that may be implicitly converted to a string...) that may not be atomized, so you cant just compare the references which may be distinct, even if the strings are comparing equal.
The == operator on pairs of Strings is not comparing references but string contents. This means that the Request.QueryString["UserGroups"] will be dereferenced, and this may cause null pointer dereference exceptions. That's why there's a prior test for null (because tests with "reference == null" is NOT dereferencing the reference but actually checking if it's null or not).
There's a possibility however to avoid the null check: you may use the === operator to just compare the reference, if the result of Request.QueryString["Usergroups"] has been atomized (but it may require allocation and hashing within the static list of atoms, not a good idea if the QueryString is very large.
So yes, the best to do is to first cache the Querystring in a local string variable, and perform the two tests:
final string queryString; // cache the string value
if ((queryString = Request.QueryString["UserGroups"]) != null &&
queryString == "True") {
...
} else {
...
}
But given that the bodies of your if/else statement is just to store the result of the if()'s condition, just write this:
final string queryString; // temporary register caching the non-atomized string reference
report.IncludeGroupFiltering =
(queryString = Request.QueryString["UserGroups"]) != null &&
queryString == "True"; // compares the two strings contents
BUT ONLY IF the Request.QueryString[] contents are already atomized strings, or if their implicit conversion to string return atomized strings, save the string compares and use === instead:
final string queryString; // temporary register caching the atomized string reference
report.IncludeGroupFiltering =
(queryString = Request.QueryString["UserGroups"]) != null &&
queryString === "True"; // compares the atomized references
I will not suggest this dangerous assumption here (it's more probable that query results from a remote source will not be atomized, for security/memory reasons, unless the returned value has already been checked. Given your code, I suspect that this is performing validation on returned values from your query, so the result is most probably not atomized: the main reason of your code is to atomize the content of the Query String into a shared boolean value, which will later compare much more easily.
Note: I absolutely don't know what is the type of the value or reference returned by Request.QueryString["UserGroups"]. It may happen that this is an object that implements the "bool operator==(string)" method, or that even returns another type than bool. Storing the returned object in a string variable however will perform its conversion to a string if the object's type is not null (and if the object is compatible, otherwise you'll get an exception).
You may want to avoid this conversion of the unknown object, if the object itself can compare to a string like "True", with code like this:
report.IncludeGroupFiltering =
Request.QueryString["UserGroups"] != null &&
// uses object's operator==(string) to compare its contents OR reference.
Request.QueryString["UserGroups"] == "True";
All this depends on how you declared the QueryString[] array property of your Request object, and if the array contents can be polymorphic (varying type). If you know how it's declared, then use exactly the same type for declaring the temporary final register above, to avoid double member access to QueryString from Request, and double indexing of the QueryString array.
Here, it's impossible to know which code will be the best for you as we don't have all the declarations (C# inherits the same type complexity/ambiguity as C++, with too many implicit conversions and complex inheritance schemes).
this is my first question here so I hope I can articulate it well and hopefully it won't be too mind-numbingly easy.
I have the following class SubSim which extends Sim, which is extending MainSim. In a completely separate class (and library as well) I need to check if an object being passed through is a type of MainSim. So the following is done to check;
Type t = GetType(sim);
//in this case, sim = SubSim
if (t != null)
{
return t.BaseType == typeof(MainSim);
}
Obviously t.BaseType is going to return Sim since Type.BaseType gets the type from which the current Type directly inherits.
Short of having to do t.BaseType.BaseType to get MainSub, is there any other way to get the proper type using .NET libraries? Or are there overrides that can be redefined to return the main class?
Thank you in advance
There are 4 related standard ways:
sim is MainSim;
(sim as MainSim) != null;
sim.GetType().IsSubclassOf(typeof(MainSim));
typeof(MainSim).IsAssignableFrom(sim.GetType());
You can also create a recursive method:
bool IsMainSimType(Type t)
{ if (t == typeof(MainSim)) return true;
if (t == typeof(object) ) return false;
return IsMainSimType(t.BaseType);
}
if (sim is MainSim)
is all you need. "is" looks up the inheritance tree.
Use the is keyword:
return t is MainSim;
The 'is' option didn't work for me. It gave me the warning; "The given expression is never of the provided ('MainSim') type", I do believe however, the warning had more to do with the framework we have in place. My solution ended up being:
return t.BaseType == typeof(MainSim) || t.BaseType.IsSubclassof(typeof(MainSim));
Not as clean as I'd hoped, or as straightforward as your answers seemed. Regardless, thank you everyone for your answers. The simplicity of them makes me realize I have much to learn.
How about "is"?
http://msdn.microsoft.com/en-us/library/scekt9xw(VS.71).aspx