When I do code reviews I tend to just have a running monologue, so as I'm making sense of what I'm reading there will be a lot of "Ok, I see what that does.. Good it connects to this and calls that, alright.. and that piece depends on both of those alright.".
I think in this way it's not "oo la la this is so great!", it could be perfectly trivial boring code, but hearing somebody else actually parse and show comprehension of what you wrote is a form of positive feedback in and of itself, the feedback being "This code makes sense", when I run into parts that I don't understand I ask for explanation and when I do understand it exclaim "Ah, I got it".
I think that simple transfer of comprehension is praise to another engineer because we all want our code to be understood by others, it gives a form of implicit validation.
That said, if you see parts of the code that are good or positive characteristics (even boring trivial code can be good if it's the minimal form of itself) I definitely tend to state those characteristics, again I don't attribute them as "Wow great!" so much as "I see this is a minimal implementation" or "Ok, this complex algorithm has lots of comments", focus on the attributes of the code not so much it's inherent goodness or badness.
Any time you attribute "goodness" or "badness" to code in a code review to avoid making the engineer feel looked down upon or held on a pedestal don't say something is good or bad, but rather talk through the cause and effect of their code.
"Ok this part makes sense, ah there's a magic number here, the meaning of that value might not be well understood by the next engineer to touch this"
"I see you've got a DI container here ok so you'll have loose coupling with that repository"
"Ah there's a static dictionary here, if multiple threads are touching that dictionary we could run into some race conditions"
Notice, I'm not saying anything's good or bad, but whether the engineer should change it or not is going to be understood by the engineer whose code is being reviewed. Obviously you have to end the code review with a yay or nay, but accumulating these statements over the course of it will soften the nay's as explanation has already been made in the form of cause and effect statements when you tell them "I'd like those magic numbers fixed before checking this in".