Skip to content

Pull Requests

Johan Degraeve edited this page May 23, 2020 · 8 revisions

Contributions (Pull Requests) will help the project to grow. However I or maybe other developers that want to contribute, must be able to maintain and extend the project in the future. Therefore I'm asking you to document your code.

I will review and try to understand every line of code. Possibly I will rewrite and/or reshuffle a lot of your code and maybe also add comments, which is a good sign because it means I've understood your code.

To help me and others understand your code, apply the following good practices.

Good practices :

  • document functions
    • there are multiple sources on the Internet that explain how to document functions in Swift, including parameters and return values
    • don't hesitate to add multiple lines of explanation
  • document classes and structures
    • same remark as for functions
  • add inline comments
    • to every (or almost every) statement.
    • Comments should be complete and readable, not in short hand.
    • the comment should explain what the statement does, possibly explains also why it's done. If it's a piece of code where you've been thinking why you do it like this, write that explanation also in the comment. Others (or maybe even yourself just two weeks later) may be asking the same question when they would just be reading the code without the comments.
    • in case of doubt : just think what a reader may be asking themselves when trying to understand your code. Write down the answer to that question
  • do not comment out code that is not useful anymore, delete it
  • when commiting code, describe as detailed as possible what you did. (there's an option to first write your commit message in a text then use that file, eg if your commit message is in commit.txt, then you commit with 'git commit -F commit.txt')
  • last but not least : restrict the changes you do to the purpose of the Pull Request.

In case of doubt :

While writing code : try to put your brain let's say 2 weeks in the future. Try to figure out if you would understand in just two weeks what you've done and why you've done it that why and why not another way. If you doubt then add more comments.

Not so good practices :

  • make suggestions how to do things instead of writing code
  • refer to other projects
  • ...