Is it bad coding style to not assign a new instance to a variable?

At the top of my program I have a code segment that looks like this

var XXXAssembler = new XXXAssembler(ctx);
XXXAssembler.LoadXXX();

var YYYAssembler = new YYYAssembler(ctx );
YYYAssembler.LoadYYY();

var ZZZAssembler = new ZZZAssembler(ctx);
ZZZAssembler.LoadZZZ();

In the above logic I use each varaible once to call the respective loader, and I don't use the variables anywhere else.

I can change the code to this

new XXXAssembler(ctx).LoadXXX();
new YYYAssembler(ctx ).LoadYYY();
new ZZZAssembler(ctx).LoadZZZ();

This reduces the size of the code, but I'd like to think it simplifies it as well. I could see the usefulness of variables for debugging, but I don't think that's necessarily a 开发者_高级运维good reason. Others may disagree.

Is the non-varaible version considered bad coding style?

Unless you're going to use the object assigned to the Assembler variable, then there's no need for it.

I'd say get rid of it, clean up the code, and then if you need it later you can bring it back.

new XXXAssembler(ctx).LoadXXX(); is absolutely fine as long as you don't have use the reference returned by new XXXAssembler(ctx) elsewhere.

If u ask me, the size of the code doesn't matters. Only matter is that, when you see the code 1 year later, to know how it does what it needs to do, and how to rewrite / reuse / etc.

As you mention, the only technical reason to assign the created object to a variable is if you need to use it or look at it somewhere. If you're confident that you'll never need to do this, you don't need to create a new variable, and you can shorten up your code a bit.

But I'll offer up two caveats:

(1) I often find that I need to look at the output of a method before it returns, or at the instance of the object created by the new statement when I'm debugging. So sometimes instead of doing this:

public MyObject ReturnSomeObject()
{
    return new MyObject();
}

I'll do this instead:

public MyObject ReturnSomeObject()
{
    var myObject = new MyObject();
    return myObject;
}

Just so I can look at it in the debugger. It clutters up my code a bit, but it can be very helpful when I'm trying to figure out why something else went wrong.

(2) If you find that you can do the sort of thing you're describing very often, you may want to take a harder look at how your classes are structured. What's the point of a class that has a method that returns nothing and which doesn't modify the internal state of the class in any fashion that you're interested in? To take your example above, presumably your various LoadXXX() methods should return some sort of status code, or modify some status property of the object, or return a pointer to the file that they loaded, or, well, something. If they do, but you're not bothering to look at it - well, that's another problem. If the methods really don't need to modify any aspect of the object's internal state, then you should look strongly at making them static: it allows you to avoid running the class constructor each time you call them, it expresses their intent more clearly, and it allows the compiler to notify you of a possible inconsistency if you do decide that they need to modify the object state at some point in the future.

Nothing hard-and-fast here, just some guidelines.

If you are never going to use the Object again, but for this case, I don't see the point in giving them names. It adds needless lines of clutter to your code.

I think not assiging to a variable is fine. I do this in many cases, e.g. for some unittest mocks new Mock<IInterfaceToMock>.Object or for callbacks functors SomeFunctionAcceptingCallback(args, new CallbackHandler()).