Codiga Rewards Program Rules

Few weeks ago, we announced our rewards program for all contributors of our Coding Assistant. The response from the community has been overwhelmingly positive and we are very thankful for all your contributions, making our coding assistant better every day.

In order to keep the quality of all contributions, are bringing rules for all contributors that want to qualify for rewards. In order to redeem rewards, contributions have to satisfy the following requirements.

Keeping in mind the end goal

All Codiga recipes are small and reusable code blocks that can be found by any developer in their IDE. Our algorithm that finds code recipes in the IDE relies on the information you provide to find the relevant recipes and for that reason, the quality of the data (name, keywords, and tags) is really important.

In addition, these code blocks should be small to be imported into the IDE. A code snippet should not be a full program but one function that can be quickly imported into the IDE and reused by another developer.

Rules

Code should be correctly indentent with 2 spaces

The code should be correctly indented with 2 spaces per indentation.

Respect naming conventions

Use the conventions for your language, starting by casing:

For Python, use snake_case
For JavaScript/TypeScript, use camelCase

Stick to the conventions that are commonly used for the language you use for your recipe.

Recipes should not be dependent on your environment

The recipe should work as is, as soon as the user imports them. They should not be dependent of your environment:

for Java, local JAR files or dependency
for Python, other files, library or data

You quickly get the idea: the code should be self-sufficient.

Put imports and other dependencies information in the imports section

If you write a Python or Java recipe, your code should not have any import. If you write a C++/C library, your recipe should not have any #include. Instead, these lines goes to the Imports section of the library so that they are added correctly to the client when using the recipe.

Recipes that do not correctly use the imports will not be subject to rewards.

Do not post code from competitive programming websites

We already have 10 variations of 2-sums and 20 variations of how to detect a palindrome. Please do not put code that are about solutions of problems from leetcode and other competitive websites.

Write generic code

Write code that is generic and can be reused by anybody. Do not share code that is specific to a use-case. For example, if you write a function that sorts a list, write a generic function to do it, not to a specific use case (e.g. a class you use in your software).

No main function or a placeholder class `Solution` or `Recipe`

The goal of Coding Assistant is to provide safe and reusable code blocks any user can import into their IDE (using our VS Code, JetBrains, or Chrome extension). For that reason, recipes should not have a main function and just a few lines of code that can be easily reused by other developers with minimal effort.

Write a function, do not get the input of the function

Write a function or a block of code that is useful. Do not get the inputs of the function first.

For example, if you want to create a recipe to test that two strings are equal, do not write

string1 = input('Enter the first string: ')
# second string
string2 = input('Enter the second string: ')
# check strings is equal or not
if(string1 == string2):
    print('The strings are the same.')
else:
    print('The strings are not the same.')

Instead, write

def are_strings_equal(str1, str2):
  return str1 == str2

The latter solution

Is smaller
Is reusable
Has a name that clearly shows what it does

Short Code Snippets

Code snippets should be small by nature. They are small code units developers can understand quickly and import in their IDE. A recipe that is more than 20 lines should be probably broken down into multiple recipes.

Useful name

The name of your recipe should describe what your recipe does. A single word is not enough for the recipe name. If your recipe reads a JSON file into a variable, use read JSON file as a recipe name. If your recipe finds the longest height of a tree, use find tree depth.

Unique tags and keywords

Tags and keywords are used to index recipes and help developers find them in their IDE. Using the same set of keywords or tags for different recipes does not help users find your recipes. For that reason, you should not use the same set of recipes and tags.

Useful tags and keywords

Your tags and keywords should reflect what your recipe does. Keywords help developers find recipes. If your recipe create a react functional component, use the keyword create, react, functional, component. If your recipe defines a function to reads a JSON file in C++, use the keywords read, json, file.

Your tags and keywords should not:

Use any special character, only alphanumeric characters, the - and _ characters
Include the language of the recipe (that is specified in the recipe itself)
Include any stop world (e.g. the, he, she, a, etc).

No repetitive code

We want recipes to be unique and useful to our developers. We do not repeat ourselves and follow the DRY principles. The same code should not be used in different recipes.

Closing remarks

Making sure your recipes are useful and correctly defined to be indexed by our matching engine is important. It helps developers find appropriate, safe reusable blocks of code and import them directly into their IDE. It is also important for you too as our next rewards program will be focused on recipes usage. The more your recipes are being used, the more rewards you will be able to accumulate.

If you have any questions about our rewards program, please join our Slack channel.