Request to contributors

[sauravjaiswalsj]

Contributing

How to contribute an implementation (code)?

• Have a look at open issues. They contain the list of algorithms/DS we plan
  to be implemented. Pick an unassigned issue.
• You can also create a new issue for an algorithm that is not in the list.
• Make sure you are assigned for the issue.
• Code the algorithm/DS following the styleguide defined below.
• Send a PR.
• Be sure to not include any compiled binaries in the patch.
• While sending a PR make sure you follow one issue per PR rule.

Suggesting an algorithm / DS

• First make sure you are not suggesting a duplicate.
• If not, proceed and create the issue. Make sure that you specify only one
  language in an issue. Create multiple issues for different languages.
• Title of issue should be of the following format -

  [Algo/Data Structure] Algorithm/DS Name [Language]
  

• Please include at least one external link for the algorithm/DS in the
  issue's body for each issue. The link should explain the algorithm/problem/DS
  in detail.

Use a Consistent Coding Style

• Code submitted should be modular.
• Don't use global variables.
• Use separate folders for each concept. Folder name should be in full
  lowercase. If the algorithm/DS name has multiple words, separate them by
  underscores. (eg longest_common_subsequence)
• Filename should be derived from the folder name. (e.g,
  longest_common_subsequence becomes longest_common_subsequence.c or
  longest_common_subsequence.java)
• Name of master function of the code should be kept same as filename to the
  best extent possible.
• Prefer classes instead of multiple helper functions (where applicable).
• Currently we are accepting contributions in C, C++, Java and Python
  but other languages may be considered after a discussion.
• Define tester code only in main routine.
• Use meaningful variable, method and function names and comments.
• No profanity.
• Use external libraries only when no other solution is possible/plausible.
• We have defined skeleton codes for some popular languages
  below. Please follow them whenever possible.

Write Good Commit Messages

A commit message consists of 3 parts:

• shortlog
• commit body
• issue reference
  Example:

quicksort.py Add QuickSort Algorithm

This adds QuickSort Algorithm which return the concatenation of the
quicksorted list of elements that are less than or equal to the pivot, the
pivot, and the quicksorted list of elements that are greater than the pivot.

Closes https://github.com/NITSkmOS/Algorithms/issues/2

Shortlog

Example:

quicksort.py: Add QuickSort Algorithm

• Maximum of 50 characters.

  Keeping subject lines at this length ensures that they are readable, and
  explains the change in a concise way.

• Should describe the change - the action being done in the commit.

• Should not include WIP prefix.

• Should have a tag and a short description separated by a colon (:)

  • Tag

    • The file or class or package being modified.
    • Not mandatory.

  • Short Description

    • Starts with a capital letter.
    • Written in imperative present tense (i.e. Add something, not Adding something or Added something).
    • No trailing period.

Commit Body

Example:

This adds QuickSort Algorithm which return the concatenation of the
quicksorted list of elements that are less than or equal to the pivot, the
pivot, and the quicksorted list of elements that are greater than the pivot.

• Maximum of 72 chars excluding newline for each line.

  The recommendation is to add a line break at 72 characters, so that Git has
  plenty of room to indent text while still keeping everything under 80
  characters overall.

• Not mandatory - but helps explain what you’re doing.

• Should describe the reasoning for your changes. This is especially important
  for complex changes that are not self explanatory. This is also the right place
  to write about related bugs.

• First person should not be used here.

Issue reference

Example:

Closes #000 
Closes https://github.com/NITSkmOS/Algorithms/issues/2

• Should use the Fixes keyword if your commit fixes a bug, or Closes if it
  adds a feature/enhancement.
• In some situations, e.g. bugs overcome in documents, the difference between
  Fixes and Closes may be very small and subjective. If a specific issue may
  lead to an unintended behaviour from the user or from the program it should be
  considered a bug, and should be addresed with Fixes. If an issue is labelled
  with bug you should always use Fixes. For all other issues use Closes.
• Should use full URL to the issue.
• There should be a single space between the Fixes or Closes and the URL.

Note:

• The issue reference will automatically add the link of the commit in the
  issue.
• It will also automatically close the issue when the commit is accepted into
  repository.