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.
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
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
#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
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.')
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.
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
component. If your recipe defines a function to reads a JSON file in C++, use the keywords
Your tags and keywords should not:
- Use any special character, only alphanumeric characters, the
- Include the language of the recipe (that is specified in the recipe itself)
- Include any stop world (e.g.
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.
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.