Original Post — Direct link

Apex the game where 1200 ≠ 1200

External link →
14 days ago - /u/RobotHavGunz - Direct link

So, like officially, i have literal nightmares about situations like this. I wrote - or at least inherited and rewrote - most of the original number shortening and formatting logic in Apex. It's been mostly replaced by a new system now, but the guts are mostly the same, so I have great empathy both for my teammate who wrote this code and for you having experienced what I guess I'd call a "quirk" of the system.

And - having done number shortening and formatting on another game as well - I can say that is probably one of the most complex and most "GOTCHA!" prone systems you can imagine. Largely because there's way, way more subjectivity than there might seem. Truncating trailing zeros, for example. 1.20K makes sense. But 1.20 makes less sense. Sometimes you want to round up.

This was probably a case where round down was better, but like, let's say you were 1 CM short, would 1,199 really make sense to round to 1.19 rather 1.20? It makes sense but also doesn't. It's made even more complicated by weird formatting rules that are of course non-standard. Like, US is comma between thousands and period before decimals, but many (most?) other places are the opposite. I remember just like spamming YUNo guy in Slack every time I'd get a bug about some edge case that I missed when I fixed the latest batch of bugs with formatting.

Compared to localized string formatting and truncation of numbers, math is easy... Well, some math...

14 days ago - /u/RobotHavGunz - Direct link

Originally posted by EnzoVulkoor

I don't know I get where you're coming from a graphic design standpoint, but on the user side of it. Rounding up is way worse as it makes you think you have enough for something when you don't. Like if your bank did this when you were going out for lunch the day before your next paycheck. You think you could splurge on something but you can't, you're in line to pay, you've made the order for it and nope bank rounded up.

in this case, yes. But - per your bank example - your bank basically knows that (almost) every number they are every dealing with - at least every number that might need to be formatted - is a currency. So they can apply rules accordingly. Like, because it's currency, your bank is rarely going to - if ever - truncate a number for UI "neatness." Your bank is always going to favor absolute precision in every case. But we use the same rounding and truncation logic for basically everything. Damage, kills, games played, KDR, and currency. And yes, we could "always round down." But does that make as much sense for games played? Or damage? I am less sure. And yes, you can make it like an optional arg - round down/round up - but then you have to think through what's "best" in every case, and then make sure you have test cases for all those things, and ... Well, that's why I had found this be such a whack-a-mole type of debugging process to get right.