„10 tips for better Pull Requests” (2015)

https://blog.ploeh.dk/2015/01/15/10-tips-for-bette... link-img
✶ pre 243 dana ✚ pre 247 dana
Web Developer at Startit

Imali smo nedavno diskusiju Pull Request vs Pair Programming, evo jednog kul članka u sličnoj zoni.


Iz članka:

Here's a list of tips to make your Pull Request better. It isn't exhaustive, but I think it addresses some of the more important aspects of creating a good Pull Request.

1. Make it small

A small, focused Pull Request gives you the best chance of having it accepted.

2. Do only one thing

Just as the Single Responsibility Principle states that a class should have only one responsibility, so should a Pull Request address only a single concern.

3. Watch your line width

The reviewer of your Pull Request will most likely be reviewing your contribution using a diff tool. Both GitHub and Stash provide browser-based diff views for reviewing. A reviewer can even configure the diff view to be side-by-side; it makes it much easier to understand what changes are included in the contribution, but it also means that the code must be readable on half a screen.

4. Avoid re-formatting

You may feel the urge to change the formatting of the existing code to fit 'your' style. Please abstain.

5. Make sure the code builds

Before submitting a Pull Request, build it on your own machine. True, works on my machine isn't particularly useful, but it's a minimum bar. If it doesn't work on your machine, it's unlikely to work on other machines as well.

6. Make sure all tests pass

Assuming that the code base in question has automated tests, make sure all tests pass before submitting a Pull Request.

7. Add tests

Again, assuming that the code in question already has automated (unit) tests, do add tests for the code you submit.

8. Document your reasoning

Self-documenting code rarely is.

9. Write well

Write good code, but also write good prose. This is partly subjective, but there are rules for both code and prose. Code has correctness rules: if you break them, it doesn't compile (or, for interpreted languages, it fails at run-time).

10. Avoid thrashing

Sometimes, a reviewer will point out various issues with your Pull Request, and you'll agree to address them.



11. Don't do PRs.

Vidi još komentara u ovoj diskusiji i pridruži se

Neregistrovani korisnici mogu videti samo jedan komentar — registracija je besplatna i može da traje i samo 10s putem Linkedina. Na ovom postu su učestvovali:


Registruj ili prijavi.


avatar Anon pre 12 dana
avatar Vukašin pre 8 dana