Question: Is there a reason to prefer using shared instance variable in class vs. local variable and have methods return the instance to it? Or is either one a bad practice?

```
import package.AClass;

public class foo {
    private AClass aVar = new AClass();

    // ... Constructor

    public AClass returnAClassSetted() {
     doStuff(aVar);

     return avar;
    }

    private void doStuff(AClass a) {
     aVar = a.setSomething("");
    }
}

```

vs. 

```
import package.AClass;

public class foo {

    // ... Constructor

    public AClass returnAClassSetted() {
     AClass aVar = new AClass();
     aVar = doStuff();

     return aVar;
    }

    private AClass doStuff() {
     AClass aVar1 = new AClass();
     aVar1.setSomething("");

     return aVar1;
    }
}

```

First one makes more sense to me in so many ways but I often see code that does the second. Thanks!

Answer: 
Instance variables are shared by all methods in the class. When one method changes the data, another method can be affected by it. It means that you can't understand any one method on its own since it is affected by the code in the other methods in the class. The order in which methods are called can affect the outcome. The methods may not be reentrant. That means that if the method is called, again, before it finishes its execution (say it calls a method that then calls it, or fires an event which then a listener calls the method) then it may fail or behave incorrectly since the data is shared. If that wasn't enough potential problems, when you have multithreading, the data could be changed while you are using it causing inconsistent and hard to reproduce bugs (race conditions).

Using local variables keeps the scope minimized to the smallest amount of code that needs it. This makes it easier to understand, and to debug. It avoids race conditions. It is easier to ensure the method is reentrant. It is a good practice to minimize the scope of data.
Instance properties represent the state of a specific instance of that Class. It might make more sense to think about a concrete example. If the class is Engine, one of the properties that might represent the state of the Engine might be

```
private boolean running;

```

... so given an instance of Engine, you could call engine.isRunning() to check the state.

If a given property is not part of the state (or composition) of your Class, then it might be best suited to be a local variable within a method, as implementation detail.