I don't know enough about how your motors are wired up and arranged to guess what that sketch will do, but it doesn't contain any of the sort of feedback logic I'd expect to see in a balance bot. Taken in conjunction with the half second delays and serial output in the 'real time' loop makes me skeptical that this sketch actually balances anything. Have I misunderstood what you're trying to do?
To address the specific question you're asking about, you don't say what the accelerometer output values are but the code implies that the accelerometer produces a signed value with zero meaning 'no acceleration' and positive/negative values corresponding to forward/backwards acceleration (I haven't bothered to work out which is which).
In that case, if you want the bot to settle around the 'zero' position, there are two approaches.
What you're doing now applies full power in whichever direction is needed and in that case you could simply switch the motor off if the 'bot is 'close enough' to balanced - and hope you can catch it when it starts to fall. The code for that would be something like:
if(xVal < -50)
{
// falling forwards, apply forward power
forward();
}
else if (xVal < 50)
{
// in the dead band - stop motors
stop();
}
else
{
// falling backwards, apply backward power
backward
}
I'm skeptical that this will actually achieve a balance, but this achieves what you seem to want the code to do.
The other approach you could take is to vary the speed and direction of the motor according to how far the 'bot is away from the balance point. With that approach the speed naturally drops down to zero as the 'bot reaches the balance point and you don't need an explicit dead band. This approach is IMO likely to give better behaviour, assuming that your sensors and overall feedback algorithm is sufficient to achieve a balance at all - which I'm not convinced about.