Julio Biason
5 years ago
3 changed files with 34 additions and 1 deletions
@ -0,0 +1,32 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - The Right Tool Is More Obvious Than You Think" |
||||
date = 2019-07-16 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "code reviews", "code style"] |
||||
+++ |
||||
|
||||
When doing code reviews, do not focus on style; focus on design things that |
||||
look a bit weird. |
||||
|
||||
<!-- more --> |
||||
|
||||
Code reviews are designed to spread knowledge around the team, with focus on |
||||
construction and problem description. Does the sequence of code gives you an |
||||
understanding on what it is trying to do? Does it contains something you know |
||||
it will make things harder to read in the future? Does it miss the point? |
||||
|
||||
That's the things you should focus. |
||||
|
||||
If the author of the code missed a space here, left a blank line there... |
||||
that's of no consequence in a code review. This is not the thing to discuss in |
||||
the code review. |
||||
|
||||
And people _hate_ people who go through code reviews just to point |
||||
missing/extra spaces and lines. |
||||
|
||||
On the other hand, if you find something weird in the code which is something |
||||
you want the author to recheck, _then_ you're free to comment that "it would |
||||
be good" if they fix the style. But that's it. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/right-tool-obvious", prev_chapter_title="The Right Tool Is More Obvious Than You Think") }} |
Loading…
Reference in new issue