Question

Lately I have been spending a lot of time ensuring that my objects all had names that would allow easy identification of their meaning. I have also discovered that you can use objects in a one time fashion like so:

_ProfileList = (New RegistryManager).GetAllProfiles()

As opposed to creating a named object.

Is there a reason not to do this when all you want is one time access to an object? If anyone knows the pro’s and cons that would be great.

PS: It is VB.NET code but either it or C# will be fine if providing examples

Answer 1

That is explicit – it just isn’t stored in a variable (indeed, the object never has a “name” – only local variables/fields have names). If you don’t need the object more than once, and it doesn’t make the core more complicated, then there is no real disadvantage to this. Note that if the object is IDisposable or similar, you will want a local, i.e.

using(var manager = new RegistryManager()) {
     _ProfileList = manager.GetAllProfiles();
}

but other than that, it doesn’t care. Indeed, if you do assign to a local and use it right away, I would expect any “release” build to remove the variable completely anyway, meaning that once compiled (in release)

var manager = new RegistryManager();
_ProfileList = manager .GetAllProfiles();

and

_ProfileList = (new RegistryManager()).GetAllProfiles();

are identical (my expectation).