Skip to content

Commit

Permalink
added more resources
Browse files Browse the repository at this point in the history
  • Loading branch information
theile committed Nov 19, 2019
1 parent 3ddffa0 commit 0dbcd90
Show file tree
Hide file tree
Showing 2 changed files with 37 additions and 4 deletions.
33 changes: 30 additions & 3 deletions HowToCodeReview.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,10 +53,37 @@ If you (the author of code) want your code to be reviewed, please try to make li

## More information, Links

https://en.wikipedia.org/wiki/Software_architecture
[Code Review For and By Scientists]( https://arxiv.org/pdf/1407.5648v2.pdf ): Abstract:
"We describe two pilot studies of code review by andfor scientists. Our principal findings are that scien-tists are enthusiastic, but need to be shown code re-view in action, and that just-in-time review of smallcode changes is more likely to succeed than large-scaleend-of-work reviews."

https://en.wikipedia.org/wiki/Code_review
[Code reviews: the lab meeting for code]( http://fperez.org/py4science/code_reviews.html )
Guidelines derived from scientific group code reviews. E.g.:
"The most difficult part of writing code is always to make it understandable to other people, including yourself a few months down the track. There’s certainly no shame in finding out that your code wasn’t as easy to understand or use as you’d hoped, so don’t take it personally when it happens (which it always does, at least in my experience), but treat it as an opportunity to improve.

Here’s some general guidelines for making your code review go smoothly:

* Make sure the motivation for your code is clear. Someone who isn’t intimately involved with your project should understand from the module documentation and the comments what you are trying to do, what approach you’re taking, and why they should expect it to work.
* Take some time to prepare a presentation about your code that will answer the above questions even for someone who hasn’t read the code. You’re more likely to get useful feedback, rather than nitpicking about syntax, if the audience can see the big picture.
* Get the code sent out at least a few days beforehand along with some background about what to look at (if large), whether suggestions should be about architecture/implementation/algorithm/requirements, etc. Make sure everyone has enough time to read the code beforehand, and don’t send a series of updated versions immediately before code review.
* Don’t try to present too much. 200 lines is an absolute maximum – 50 is usually more reasonable.
* ...
"

[Code review guidelines](https://www.codeproject.com/articles/524235/codeplusreviewplusguidelines) by codeproject is document like this one and explains the why and how with practical tips for reviewers and authors.

[11 best practices for code review]( https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/index.html)
1. Review fewer than 200–400 lines of code at a time
3. Take enough time for a proper, slow review, but not more than 60–90 minutes
4. Be sure that authors annotate source code before the review begins
...

[Code Review Guidelines for Humans](https://phauer.com/2018/code-review-guidelines/) - How to do code reviews without destroying relationships.

List of links with content about code reviews - https://github.com/joho/awesome-code-review

Google Engineering Practices Documentation - https://google.github.io/eng-practices/

List of good resources around code reviews - https://github.com/joho/awesome-code-review
https://en.wikipedia.org/wiki/Software_architecture

https://en.wikipedia.org/wiki/Code_review

8 changes: 7 additions & 1 deletion usingGit.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,4 +6,10 @@ It allows you to view and restore old versions of your files and manage the coll

## How to use Git

Git is a command-line program but you can use a graphical user interface if you prefer. Possible GUIs are TortoiseGit (available through the MPIDR software repository in the intranet) or Github Desktop or [many others]( https://git-scm.com/downloads/guis/ )
Git is a command-line program but you can use a graphical user interface if you prefer. Possible GUIs are TortoiseGit (available through the MPIDR software repository in the intranet) or Github Desktop or [many others]( https://git-scm.com/downloads/guis/ ). Either way you first have to install the command-line program through the MPIDR software repository).

## Recommended software

## Recommended Tutorials

There are a lot of very good tutorials on how to use Git available on the internet.

0 comments on commit 0dbcd90

Please sign in to comment.