There are two notable issues in the question, the tactfully part, and the deadline coming up part. These are distinct issues - the first is a question of communication and team-dynamics, the second is a question of planning and prioritization.
Tactfully. I assume you want to avoid brushed egos and negative pushback against the reviews. Some suggestions:
- Have a shared understanding on coding standards and design principles.
- Never criticize or review the developer, only the code. Avoid the word "you" or "your code", just talk about the code under review, detached from any developer.
- Put your pride into the quality of the completed code, such that review comments which help improve the end result are appreciated.
- Suggest improvements rather than demand. Always have a dialogue if you disagree. Try to understand the other point of view when you disagree.
- Have the reviews go both ways. I.e. have the person you reviewed review your code next. Don't have "one-way" reviews.
The second part is the prioritization. You have many suggestions for improvements, but since deadline is approaching there is only time to apply a few.
Well, first you want to avoid this happen in the first place! You do this by performing continuous, incremental reviews. Don't let a developer work for weeks on a feature and then review it all at the last moment. Secondly, code reviews and time to implement review suggestions should be part of the regular planning and estimates for any task. If there is not enough time to review properly, something have gone wrong in planning.
But lets assume something have gone wrong in the process, and you are now faced with a number of review comments, and you do not have time to implement them all. You have to prioritize. Then go for the changes which will be hardest and riskiest to change later if you postpone it.
Naming of identifiers in source code is incredibly important for readability and maintainability, but it is also pretty easy and low-risk to change in the future. Same with code formatting. So don't focus on that stuff. On the other hand, sanity of publicly exposed interfaces should be highest priority, since they are really hard to change in the future. Persistent data is hard to change - if you first start storing inconsistent or incomplete data in a database it is really hard to fix in the future.
Areas which are covered by unit-tests are low risk. You can always fix those later. Areas which is not, but which could be unit-tested are lower risk than areas which cannot be unit-tested.
Say you have a big chunk of code with no unit tests and all kinds of code quality issues including a hardcoded dependency on an external service. By instead injecting this dependency, you make the code chunk testable. This means you can in the future add tests and then work on fixing the rest of the issues. With the hardcoded dependency you cannot even add tests. So go for this fix first.
But please try to avoid ending up in this scenario in the first place!