Timeline for What is the best way for a programmer to handle being code reviewed?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 30, 2017 at 8:28 | history | edited | Giorgio | CC BY-SA 3.0 | Extended discussion |
| Aug 4, 2014 at 10:12 | comment | added | Giorgio | @scragar: True: one always tries to stick to the facts. However, it can be tiresome sometimes. Example (in the context of a rather extensive commit): you have to compare a std::string with a QString. Your solution: Convert std::string to QString and use QString method to compare. Reviewer's change: convert QString to std::string and use std::string method to compare. You can think about infinite variations on how to change code into equivalent code just to show that you have been there. It is very important to distinguish between constructive feedback and nitpicking. | |
| Aug 4, 2014 at 10:07 | comment | added | scragar | I've found that if I ever feel myself coming across as a 3 or 4 I have to either demonstrate what they're doing is actually broken("See, this actually does fail if the customers last name is Null") or write out both solutions, and check to see if my proposed solution is actually worth the change(maybe my code is more readable but slower, or vice versa, in these instances I'll normally not bother perusing the change, unless the difference is significant(either in readability or speed)). | |
| Aug 4, 2014 at 9:47 | history | answered | Giorgio | CC BY-SA 3.0 |