Code Review iterations

Question

I posted a question at the https://codereview.stackexchange.com and got the answer, what's now?

I can't find to respective guide, so this a question of appropriate processing of the question/answer at the site.

The answer could contain (not all of these took place in the answer to my question, but I tried to collect most common questions I could have tomorrow):

1. Suggestions for changes in code which I agree with, but not sure I got correctly or could implement correctly, so I need the next code review revision. Should I create a new Code Review for it? If so, how should I name it (the same name + Version 2?)?
2. Questions on the reasons for my design decisions. How should I answer to them, in form of comments?
3. Wrong points of review because of my explicit statements in question were ignored or misunderstood. Should I stress this in form of comments or just ignore? The problem is that misunderstanding could have led whole code review in wrong way.
4. Recommendations I don't understand. Should I ask for clarifications in form of comments?
5. Recommendations I strongly disagree with. Should I ignore them and take this just a position of another person (two programmers is always three opinions) or can I start the argument in form of comments?
6. Irrelevant recommendations which are closer to personal programming style. Should I just ignore to avoid holy wars?

It would be nice if there is some guide, FAQ or something like this for the https://codereview.stackexchange.com. I failed to find it, so asking for advice here. Could you please provide the link or recommend your way of handling things?

• Sᴀᴍ Onᴇᴌᴀ: Did you look at this meta CR post How to post a follow-up question? and in the CR help Section What should I do when someone answers my question? under the heading I improved my code based on the reviews. What next? List Item #1?
• Damir Tenishev: @SᴀᴍOnᴇᴌᴀ, thank you, it helps, but answers only to part of the questions. I will comment under the answer from Toby Speight below.

Answer 1

Pretty much everything you mention in 1, 2, 3 and 5 can be incorporated into your code (either functionally in the code or its tests, or by renaming identifiers or adding comments to it that explain the reasoning) then posted as a new review request or (with a summary of changes) as a self-answer.

If you don't understand a recommendation (4), then I would expect you to leave a reply under the answer requesting clarification.

Style suggestions (6) I'd expect you to take or leave according to taste - no need to reply unless you think a suggested style is actively harmful.

• Damir Tenishev: Thank you. Let me answer one by one because of the limited length of the comment. 1. I am happy to create a new code review, although some other guidelines say I should post self-answer with the next iteration. Never mind, the key question for me is the best version of the name for the next code review question. I don't really like "another A" like in examples, since "another" have different meaning in English like "another person just reinvented A", the key is this "another" doesn't say that this is the next step. I would prefer "Version B"; would it work?
• Damir Tenishev: 2. Should I incorporate answers to questions on my design decisions in code? Are you sure? Shouldn't this be provided in form of comments under code review? I can't understand how you'd like to put this into the code. In form of comments? This would lead to very bad programming style.
• Damir Tenishev: 3. I am not sure we are on the same page, as well. The reviewer missed my points which specify the requirements and does misleading review, why should I change my code and put these points in the code? Shouldn't I point on this in form of comments?
• Damir Tenishev: 5. You lost me. Why should I incorporate recommendations I strongly disagree with?
• Damir Tenishev: And we are on the same page with (4) and (6).
• Toby Speight: If there's some aspect of your code that's not obvious to someone (perhaps Future You) then you want to discourage that well-intentioned person from changing the code to use the method you specifically discounted. The best place to put the warning is in the code itself, in my opinion.
• Toby Speight: As to whether (a) a new question, (b) a self-answer or (c) a link to code is most appropriate, that really depends on whether you want (a) to have your improved code reviewed, (b) to show how you improved it or (c) to share the finished code. Take your pick. (Sorry I didn't mention case (c) in my answer; I think it's the least valuable option.)
• Toby Speight: Just to clarify on 5: if there's a good reason to reject a recommendation, then a comment explaining why that approach is unsuitable is extremely valuable to readers (and may even be the reason you wrote the code in the first place). A simple example: /* Boost has a function for this, but we don't want to require it just for this one use */.
• Damir Tenishev: Thank you, I got your points. Will do my best to follow.