As well as designing a new system for our company. My partner and I are also trying to come up with a clear set of Company Coding Standards for new people who join our company.
We ran into something that I believe is personal preference but I'm not sure. So maybe I can get some suggestions :)
Our thing is when to fully declare an object. We have agreed that all variable/private members must be declared at the top of method or class.
What we don't agree on is how to declare a reference type. I like the following syntax:
private MyObject WorkWithMyObject()
{
MyObject _CurrentObject = new MyObject( );
//WORK WITH MY OBJECT
return _CurrentObject;
}
My partner says to declare it as null first. then initialize it when needed as its not good to hold that memory when it's being declared because if we don't use it then were holding memory for nothing. He likes it like so:
private MyObject WorkWithMyObject()
{
MyObject _CurrentObject = null;
_CurrentObject = new MyObject( );
//DO SOME WORK WITH "_CurrentObject"
if (_CurrentObject == null)
return new MyObject();
else
return _CurrentObject;
}
Is this personal preference or is there a technical advantage one way or the other?
hi
here are my two cents: my personal preference is same as yr friends. even if we use lazy loading for objects properites, the object shud be instantied when used. also there can be conditions like:
private MyObject WorkwithMyObject()
{
MyObject current = new My Object();
//working with my object
//some error
return current;
}
Now this will return an instantiated but possibly corrupted object. I dont think its right to do that. but ill await other suggestions on the same.
vivek
The older preference was to declare all of your variables at the top of the method and then instantiate them when you wanted to use them. With Dotnet, the advise is typically the opposite, do not declare your variables until you are ready to use them. Keep the variable declaration as close to the use as possible for maintainability. (This is echoed in the excellent Code Complete book as well.)
There are cases where you would want to separate your instantiation from the declaration. Consider a polymorphic factory example:
public shared function GetVal(inputVal as string) as BusinessBase
Dim myObj as BusinessBase
select case inputVal
case "1stCase"
myObj = CustomObj1.GetObj()
case "2ndCase"
myObj = CustomObj2.GetObj()
case else
throw new ArgumentException("Unable to fetch object type " & inputVal)
end Select
return myObj
end function
Here, we need to declare myObj as a type before it is instantiated and outside of the case statement as we want to use it once we exit the case statement. The same is true for structured exception handling where an object must be declared outside of the exception block and then typically instantiated inside of the try block in order to finalize it in the Finally block (assuming you are not using Using...)
There are cases for both methods. I would recommend keeping the instantiation as close to the use as possible to facilitate code maintenance. Unless C# handles the instantiation differently, I don't think initializing the object to Nothing/Null explicitly offers any advantage as that is the default for all reference types.
Jim Wooley
http://devauthority.com/blogs/jwooley
I would recommend
Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers by Francesco Balena, Giuseppe DiMauro ( http://www.amazon.com/gp/product/0735621721/sr=1-3/qid=1153961023/ref=pd_bbs_3/103-9833135-5151866?ie=UTF8&s=books )
Igor
Copyright (c) Marimer LLC