Ordinarily, I'd simply argue that if a user is continuing to repeat the same mistakes which have already been pointed out in answers they've received before, then simply downvote, and leave a comment pointing to the previous answers (and don't provide a new answer).
But I want to address the specific case of:
I must do it X-way because my professor requires it.
And when I specific, I mean that the stuff that must be done is in reference only to things that would be non-public to any user of the code.1
When we are not allowed to change internal aspects of our code, we begin to venture into the area of not being the owner or maintainer of the code.
However, projects outside the classroom do have business requirements. And, absurdly enough, the business requirements can sometimes reach really, really deep into effecting how you write your code. Additionally, professional shops all have their own set of standards & conventions for how code is written there.
So, if there are requirements of this nature, they should be part of the question.
With that said, I can see how it would be very easy to not see how one of the requirements you are bound by is in direct conflict with some recommendations you will receive. But once the recommendation is made, editing relevant requirements into your question and certainly making them part of any future questions seems absolutely the right thing to do.
Anything else is just wasting people's time.
- Are previous review comments being ignored? If so, I should abstain from posting further reviews, downvote, and move on (the asker clearly does not want any and all aspects to be reviewed).
- Are previous review comments not understood by the asker? If so, I need to know so that I can come up with an alternate explanation. Maybe I need a 1-on-1 chat with the asker to actually explain the issue.
- Is the asker bound by some sort of requirements that prevent them from implementing previous review comments? If so, those requirements should be part of the question so everyone is on the same page.
1. Clearly, if you are, for example, implementing some code in a library, not being able to change the public-facing API seems a reasonable requirement. However, not being able to change the private methods internal to the library crosses the line into an unreasonable requirement (as just one example).