You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code reviews require a lot of time and effort, but reasonable policies for doing short but effective code reviews can help with the maintainability of the software.
Accessible?
Yes, except for the SQL query, but I think that's fine.
Size?
Is the chapter the right length? Yes
Should anything missing be added?
Please briefly mention where the data was from. The chapter seems to skip straight from an introduction/motivation to results.
I feel like the writing could use a bit more narrative. There are some nice lessons there, but they're not tied together in terms of the writing structure.
Can anything superfluous be removed (e.g. by deleting some section that does not work so well or by using less jargon, less formulae, lees diagrams, less references).?
No
What are the aspects of the chapter that authors SHOULD change?
Some typos: "frequently supporting" -> "frequently support", "But with abundance" -> "But with an abundance", "the harder is" -> "the harder it is"
Gotta Mantra?
We encouraged (but did not require) the chapter title to be a mantra or something cute/catchy, i.e., some slogan reflecting best practice for data science for SE? If you have suggestion for a better title, please put them here.
Love the current title.
Best Points
What are the best points of the chapter that the authors should NOT change?
Lots of really good tips and advice on code reviews. Keep them all!
The text was updated successfully, but these errors were encountered:
Review template
Before filling in this review, please read our Advice to Reviewers.
(If you have confidential comments about this chapter, please email them to one of the book editors.)
Title of chapter
Code reviews are not for finding defects
URL to the chapter
https://github.com/ds4se/chapters/blob/master/jacekczerwonka/code_reviews.md
Message?
Code reviews require a lot of time and effort, but reasonable policies for doing short but effective code reviews can help with the maintainability of the software.
Accessible?
Yes, except for the SQL query, but I think that's fine.
Size?
Is the chapter the right length? Yes
Should anything missing be added?
Please briefly mention where the data was from. The chapter seems to skip straight from an introduction/motivation to results.
I feel like the writing could use a bit more narrative. There are some nice lessons there, but they're not tied together in terms of the writing structure.
Can anything superfluous be removed (e.g. by deleting some section that does not work so well or by using less jargon, less formulae, lees diagrams, less references).?
No
What are the aspects of the chapter that authors SHOULD change?
Some typos: "frequently supporting" -> "frequently support", "But with abundance" -> "But with an abundance", "the harder is" -> "the harder it is"
Gotta Mantra?
We encouraged (but did not require) the chapter title to be a mantra or something cute/catchy, i.e., some slogan reflecting best practice for data science for SE? If you have suggestion for a better title, please put them here.
Love the current title.
Best Points
What are the best points of the chapter that the authors should NOT change?
Lots of really good tips and advice on code reviews. Keep them all!
The text was updated successfully, but these errors were encountered: