seanh + code-reviews   16

Should you call out code style issues in a code review?
Code formatting issues should almost never come up during a code review ... Remember that the best code reviews should provoke discussions — and spending time on basic formatting issues won’t help with that goal.
code-reviews 
september 2016 by seanh
7 ways to avoid aggravation in code reviews
blunt and unfiltered communication also carries a long-term cost
Instead of pointing out obvious issues with the code (or what you feel are obvious issues with the code), it’s usually smoother to ask for clarification instead.
Ask questions; don’t make demands
code-reviews 
september 2016 by seanh
Effective Code Reviews Without the Pain - Developer.com
This is one of the most useful articles that I found about code review.
code-reviews 
september 2016 by seanh
How to Use a Code Review to Execute Someone's Soul
Nitpick and bikeshed:
I think most of us would agree that there’s nothing like spending an hour or two arguing about whether to use implicit typing or not or whether it’s better to trap a null parameter and throw ArgumentNullException or to just let the NullReferenceException happen organically. So, why not make all of your code reviews like that? You can forget about big picture concerns or pragmatic but philosophical discussions such as code readability and ease of maintenance and opt instead to have heated arguments about the little things. Anyone who had previously viewed code reviews as opportunities for learning and collaboration will quickly come to realize that they’re the place for heated disagreements about subjective opinions on details.

Be condescending and derisive.

Pass your opinions off as facts:
Is it your opinion that static methods are better than instance methods? No, of course not. It’s just a fact. At least, that’s how you should approach code reviews. Think of all of your personal tastes in design patterns, coding approaches, style, etc, and then remove qualifying phrases like “I think that,” “I prefer,” or “In my opinion.” So, “I like pre-pending field names with underscores” becomes “you should pre-pend your field names with underscores” and “I find out parameters confusing” becomes “out parameters are bad.”

Cover things for which checks could be easily automated.

Focus only on the negative.

Examples of what you _should_ do:

Ask questions instead of making statements:
"What do you think would happen if I passed null into this method?"
Allowing them to solve the problem and propose the improvement is empowering and so, so much better than giving them orders to fix their deficient code.
code-reviews 
september 2016 by seanh
Effective Code Reviews · Code Ahoy
the reviewers must show respect for the author’s talent and hard work ...

Saying, “I didn’t see where these variables were initialized” is likely to elicit a constructive response, whereas “You didn’t initialize these variables” might get the author’s hackles up.

...

It is easy to become fixated on the code, but remember, there’s a human at the other end of the table (or computer). A human who has opinions. A human who is entitled to have an ‘ego’. Remember that there are many ways to solve a problem.

...

The developer isn’t there to be sitting duck.

...

People often forget how far a simple “great job” or “it looks great” could go.

...

You are listening to another person and should genuinely seek to understand their perspective. Offer suggestions and tips when they are necessary.
code-reviews 
september 2016 by seanh
11 proven practices for more effective, efficient peer code review
4. Be sure that authors annotate source code before the review begins
code-reviews 
september 2016 by seanh
How to Facilitate Friendlier Code Reviews

Instead of improving the product and solving a problem, feedback that is purely critical can offend the team member that authored the code and cause additional problems.

Giving good feedback is a skill that you have to learn.

Make a conscious effort to be friendly in your feedback.

code-reviews 
september 2016 by seanh
How To Do Positive Code Reviews // Speaker Deck

The rule of surprises: set measurable expectations up front, then provide evidence for and against agreed, defined expectations and standards. Refusal must be evidence based against documented standards and requirements. Evidence based, not opinion based.

Ask. Don't tell.
code-reviews 
september 2016 by seanh

Copy this bookmark:



description:


tags: