I've run into a user's questions a couple of times now, and I'm finding that they seem to make the same mistakes in each question they post, like using namespace std;, or system("PAUSE");.

The user mentions that their professor requires these bad habits, so this is a little bit of a different case. With this knowledge, the habits are no longer a "mistake" but more like a requirement. Like a custom code convention (a lousy one, but still).

What should we do when we encounter users that keep making the same, obvious mistakes in their code, and they aren't required to?

Edit: The user isn't repeating the same bad habits in follow-ups, just most of their (unrelated) questions.


4 Answers 4


What should we do when we encounter users that keep making the same, obvious mistakes in their code

You're reviewing their code; you may comment on any and all aspects of the code. The unsaid is that you may comment on anywhere from a single instruction to the entire project architecture1, in an epic, blog-sized, markdown-formatted answer with \$MathJax\$ and shiny diagrams: whether you want to cover that given [bad] piece of code (again) or leave it for other reviewers to mention, is entirely up to you.

This is Stack Exchange, not FaceBook: yes we're a community, but we're first and foremost a Q&A site and I'd presume most of our readers read our answers for the quality of the review material, not for the social interactions and meta-discussions between the lines - there's chat transcripts for that. You could downvote the post (or not vote at all), and invite that user in The 2nd Monitor to see if OP wants to have that talk.

The regulars would give them a warm welcome to the site's main chatroom2, and then you could bring the main course onto the table:

I've read, answered (and upvoted) a number of your previous questions, but looking at the latest few ones I feel like half my review would sound like a broken record. May I ask if there's any specific reason for still seeing using namespace std; after reading [this answer](http://www.codereview.stackexchange.com/a/00000)?

Or whatever floats your boat. Just remember to .

Your answer shouldn't be written for the OP, but for the reader: the OP indeed, but also every user that's going to lay eyes on it, most of which will not know, notice, or care that the question they're reading is the \$n^{th}\$ time that this specific asker posted a question with using namespace std; in every code block.

If you're craving for some code to review, you could always skip the parts that make you feel like a broken record.. or, there are hundreds of zombies waiting for an answer - leaving that one in the hands of other reviewers, perhaps a new user that's attempting their first answer at that very moment, is fine too.

1 Depending on context.

2 As always.

  • 1
    \$\begingroup\$ Well said, Sir... \$\endgroup\$ Commented Sep 6, 2015 at 10:50

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).

  • 2
    \$\begingroup\$ "So, if there are requirements of this nature, they should be part of the question." That. Completely. It's very important context. \$\endgroup\$
    – Mast Mod
    Commented Aug 30, 2015 at 11:41

I feel like anybody posting their code in good faith should be treated respectfully.

If somebody appears not to incorporate suggestions into subsequent posts, ask them why.

If they aren't being required, and the OP simply prefers not to incorporate that piece of advice, tell them to indicate so in their questions, e.g. "I am aware of X best practice but instead I do Y because Z". What/how people answer/respond is then up to them.

You can bring a horse to water but you cannot force it to drink.

However, if the horse sought out the water then chances are it's intending to drink at some point, it just may take some longer than others.


If the author does not learn from all the points you make, nothing should be done.

People are often forgetful, and can simply forget some of the points you make.

For example, If I reviewed a question, and suggested string.Empty instead of "", provided they missed the former in a follow-up / newer question, it would be rude to ask; Why didn't you incorporate all those changes I suggested?

Despite small, and easily missed in a large review, it would be still rude to ask; however, what could be done is to say something like: 'As iterated over in my previous review (link to previous question), xyz is bad practice, because; \$\dots\$'

  • 4
    \$\begingroup\$ It wouldn't be rude. It's rude for someone to ask for a review and ignore the reviews (not even comment on why changes weren't incorporated). \$\endgroup\$
    – nhgrif
    Commented Aug 30, 2015 at 1:06
  • 2
    \$\begingroup\$ Really? 'Why haven't you taken on board what I said?' - That wouldn't be rude? I'd certainly find it rude. \$\endgroup\$
    – Quill
    Commented Aug 30, 2015 at 1:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .