If the code is that far off the deep end, then your job at this point needs to shift from code reviewer to teacher.
You need to patiently explain not only what is wrong, but also why it's wrong, and how to fix it, with examples. You might want to even sit down and refactor the code with him.
You need to explain the code design concepts and principles that he has missed. In short, you need to GUIDE him.
It's either that or get rid of him, because until SOMEONE teaches him, he will continue doing what he's doing and remain oblivious.
This might be a good time to do a pair programming exercise. Go through the code with them so they can see your process. For example, review the requirements, write test cases to cover those reqs, then refactor the code to work or even start from scratch if it's not that much code.
The best way for a developer to get better is to be shown a better way to do things.
it's more important that he learns how to find better ways to do things himself. I would ask him if he thinks it's
actually check-in worthy. I would continue asking until his doubt about it got the better of him, so that he views his code with a more skeptical eye. Then I would ask him to come up with 3-5 succinct ways to improve this. If they were good, I'd have him implement them.
You don't do the work for them, and you don't show them. The point of the college degree is that you've learned how to teach yourself without handholding. You need to be able to craft creativity yourself from blocks of wood.
If the 3-5 improvement ideas were bad, ask him to try again. If he still screws up [which is unlikely IMO] (and is really trying to come up with good stuff), give him one idea, ask him what he thinks of it, why, etc; have him implement it, give him another, etc.
The techniques for writing well-structured code may seem obvious to someone who has been practicing them for a long time, but they may be not at all obvious to someone who is just starting out. After all, it took a few decades in the history of programming and some very smart people like Dijkstra to convince professional programmers that code structure was important. The principles of refactoring weren't well known until much later. So I think that expecting some junior programmer to come up with these ideas by trial and error is setting them up for failure.
my own experience writing C was basically that all the fancy terms in the book didn't help me any, because they translated poorly to tacit knowledge. what helped me was running into the problems myself, coming up with the solution myself, and then realizing someone had already done it.
I'm very slow at tacit acquisition though. I needed more practice. For someone like me in the first year and a half, I would just give them the info. However, now that I have 3 years of C and C#, I can rapidly digest new design paradigms, and write much better code. If the guy purported to have 5-10 years of experience and is still writing crap, I would take issue with telling him the problems himself as he's probably one of those rote-memorization dudes that China or India pumps out with no tacit understanding.
You need to patiently explain not only what is wrong, but also why it's wrong, and how to fix it, with examples. You might want to even sit down and refactor the code with him.
I teach (not CS), but the OP should break down a small amount of code with a small number of actionable principles. He can't teach everything at once, simultaneously, without overwhelming the person he's teaching. If he has the time, he should do a small-ish amount of teaching every day, perhaps starting with the same code base and giving appropriate assignments each day.
I mostly agree, especially with the emphasis on teaching.
The way I typically deal with this situation (and it's one I encounter almost as a matter of course with new people, and they all grow beyond this) is to have a high-level, in-person conversation about the code. Many professional programmers are actually quite good (whatever you think of this particular pull request) and the conversation is a chance to simultaneously de-escalate (whereas a nit-picky code review can escalate) and give them a chance to see their code anew from your perspective.
You need to patiently explain not only what is wrong, but also why it's wrong, and how to fix it, with examples. You might want to even sit down and refactor the code with him.
You need to explain the code design concepts and principles that he has missed. In short, you need to GUIDE him.
It's either that or get rid of him, because until SOMEONE teaches him, he will continue doing what he's doing and remain oblivious.