Skip to content

Latest commit

 

History

History
40 lines (28 loc) · 3.09 KB

CONTRIBUTING.md

File metadata and controls

40 lines (28 loc) · 3.09 KB
Raw

Contributing to vcf-validator

We welcome community contributions to vcf-validator!

Bug reports & troubleshooting

If you are submitting a bug, please go to this link

First Timers Welcome!

To build tool locally, follow the instructions in the README.md file. New to open source? Here is a selection of issues we've made especially for first-timers. Follow this link.

Making a New PR

Once you found an interesting issue to work on you may check if someone other is not working on the same issue. You can ask once in the issue to get that issue assigned to you. Once you get an approval go for the PR. While making a new PR do follow these norms:

  • Fork and git clone the repository if you haven't done so.
  • Add EBIvariation as "upstream" remote: git remote add upstream https://github.com/EBIvariation/vcf-validator.git
  • Fetch the latest changes by git fetch upstream.
  • Update the local develop branch git rebase upstream/develop develop.
  • Create a new branch from develop git checkout -b <branch_name> develop.
  • Add and commit the changes, commit messages should be short and well explanatory.
  • While creating new PR, change the base from master to develop.
  • PR message should be well explanatory and should contain reference to the issue this PR is for.
  • Once the PR is ready for a review, ask for a review.

Coding Practice

There are some coding practices that we follow to make code easily readable and modifiable. Few of them that should be kept in mind while coding are:

  • Consistent Indentation - We generally prefer 4 spaces for indentation.
  • Comments & Documentation - Provide comments whenever required, so that it may be easy for other developers to read your code. Also avoid obvious comments.
  • Tests - Add tests if new functionality is added to ensure that this functionality does not break in future.
  • Consistent Naming Scheme - Follow a consistent naming scheme. We prefer snake_case(underscored) instead of camelCase. Naming of variables should be done in well explanatory way.
  • DRY Principle - Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Aslo called Don't repeat yourself
  • Avoid Deep Nesting - Too many levels of nesting make code harder to read.
  • Limit Line Length - It is a good practice to avoid writing horizontally long lines of code. There is no such limit but still having max lenght till 80 is good practice. For more follow this link.
  • Bracket Style - We generally use attached brackets for conditions and loops and broken brackets for functions and classes. Our style is a variant of K&R style : variant, difference is that we force use of brackets even if there is single statement in the brackets.