I write and review medical software. When I'm reviewing code the most important question is, "Is it correct?" If it's not, then the review simply isn't approved (obviously).

Anything that makes it harder to determine correctness is a strike against the code. This can include anything from high level organization, to comments, to the naming of variables, to the use of whitespace. For example, with respect to variable names, if you're implementing something that has to conform to the DICOM standard, then you should consider following their nomenclature, even if it may not be what you'd normally use in other contexts.

Aside from correctness issues, I'll make anything from "strong recommendations" to "mild suggestions". (In theory, any of these could cause me not to approve a change, but the closer we get to "mild suggestion" the less likely that is.) Examples might include:

- You're trying to do something with X. I'm a domain expert in X and while your code is technically correct it's not idiomatic. I suggest doing it this other way instead.

- You added a public function to a library, but it will fail if the String argument isn't a valid Photometric Interpretation. Yes, I see that you only call it with valid values, but since it's public anybody can now call it, and they may not be so diligent. How about making it an Enum?

- You have a loop that, superficially, looks like it's calculating Bar, but upon closer examination it's (correctly) calculating Bar'. How about adding a comment stating this, so that no one is tempted to (incorrectly) "fix" it?

- You've implemented a function that does Y. All our code links with the Foo library, which happens to have a function that does Y. How about using that instead?

- Your log message makes sense if you're reading the surrounding code, but someone from support seeing it in the log file won't know what to make of it. How about including this contextual information in it?

- In the loop that you added, your indentation is inconsistent with the rest of the function. How about making it the same?

- Why do you have four blanks lines in the middle of your function?

In my own code I'm pretty anal about formatting, comments, log messages, use of whitespace, etc. I'm definitely less harsh when reviewing other people's code, but I have to admit that when I see sloppy formatting, grammatical errors or gratuitous use of whitespace, I'm on the alert for sloppiness in other areas, such as design and implementation.