Yes, that's the way. See the example for computed fields, which uses RoundDecs.
8 allows formatting of values in tables. The 9 way is to apply Style to whatever you want to look different (like applying the Style pane to images, drawings, labels, etc.), but the Style pane is not yet turned on for fields in tables. It will be.
In the meantime, the nice thing about using computed fields is the accuracy of them, which you don't get with formatting in 8.
When you format the display of a floating point number in 8 to show only the first three values after the decimal point, the rest of the number is still there - it's just not being shown. What the table shows you is not exactly what the data is. So when you use that field in subsequent calculations, it's very natural to forget that you're calculating with numbers that are different than what you see, and that can lead to surprises and errors.
With 9, when you round in a computed field to only the first three values after the decimal point, what you see is what you get: that's the actual number with no hidden part. The table is showing you exactly what the data is. You can conjure with that field in subsequent calculations and the results are precisely, accurately, what you expect, with no surprises.
8 is OK with the increased risk of error in such matters. Like all the other classical GISs I know, 8 provides no warning that what the table is showing is not the actual data but an adjusted representation of it.
9 takes a more professional approach with the feeling that OK, if fewer decimals are wanted there's a way to do that accurately with no surprises - use a computed field. When Style is introduced to the table pane in 9, there will be a way to indicate that what people are looking at is not the actual number but an adjusted representation of it. It's a fine point, but an important one.