Changes that suggest "making code look nice" are mainly a matter of taste (as opposed to "making it look less ugly", but see below). Such issues have a high potential of making code reviews a highly frustrating experience. If you don't find anything else, leave early and save both of you a lot of time. Code reviews should ideally be a pleasant experience for both the reviewer and the reviewed (at least the ones I made that went that way were the most productive ones) mentioning positive things as well as criticising and discussing objectively negative aspects and proposals for improval. Style issues can easily come across as nitpicking.
Style is to many a matter of taste and if you can't come up with a tangible functional argument why it should look different, you're concentrating on the wrong things. (Maybe you should consider code reviews a chance to make yourself more familiar with other people's coding style - You're going to face and will have to live with a lot of them during your career).
When I'm saying "making it less ugly" above, I mean cases where "style" (or lack of it) negatively affects readability and thus maintainability. I've seen code with illogical line breaks, ragged comments and messy indentation. That should be pointed out and fixed (in my experience, the visual state of code and its programmer's state of mind do somewhat correlate: if one of them is messy, the other one is likely to be confused as well... Your example doesn't seem to be of that sort.
If that example dictionary wouldn't have only three, but 300 entries, I would definitely go with you that it should be alphabetically sorted. But that's then a functional argument in that it may help to avoid duplicate entries, which doesn't really apply to three.
BTW: Should you happen to have a coding convention in place at your team that says "dictionaries must be sorted", it's obviously a different story. But then I might probably question that coding convention...)