Please follow the following guidelines when creating or finding practice problems. We expect all problems submitted to maintain the highest quality!
If you have questions, send a message to #questions on the C4T Classes Discord or email us at classes@code4tomorrow.org.
This will save you time because when you submit a pull request (PR) on GitHub, we check for good programming style. Your PR will not be approved unless it passes those style checks. Also, linters basically enforce all of the style rules that we discuss below, so you basically can just skip to the next section (Follow the C4T practice and solution problem format).
- Java: Install checkstyle
- Python: Install flake8 and black
- HTML/CSS: Install Prettier and stylelint
This should go without saying, but actually use the linters! If you see errors/problems/warnings, address them, don’t ignore them and keep going!
Note: We highly recommend that you use Visual Studio Code, because it has a lot of useful extensions you can install with a few clicks (including the linters mentioned above). It also has great Version Control System (VCS) integration and extensions.
- Indent properly.
- Make sure there are spaces between binary operators, parentheses, curly braces, etc. when applicable. (For method/function calls, there should not be a space between the method/function name and the parentheses.)
- For HTML, attributes should not have spaces between the attribute name, equal sign, and attribute value
- Leave empty lines where appropriate to increase readability
- Name files so that they are representative of what the program is about. File names are also the name of the practice problem.
- Avoid naming files after concepts, like “Arrays.java”
- Java: Use class naming conventions to name files. For example, HelloWorld.java rather than helloWorld.java or hello_world.java or something else
- Python: Use snake case to name files. For example, hello_world.py rather than HelloWorld.py or helloWorld.py or something else
- Name variables/methods/functions descriptively, and follow your language’s conventions.
- Java: camelCase for regular variables, snake case (and uppercase) for constants
- Python: Snake case for regular variables, snake case (and uppercase) for constants
- If a line of code is very long, separate it into 2+ lines (e.g. for long lists/arrays, long print statements, etc.)
- Add comments to explain parts of your code
- Break up the program into methods/functions if applicable and if the students have learned about methods/functions at that point in time.
- Make sure you put the file(s) in the right directories.
- All code filed under "practice" should be templates.
- Templates may include things like an empty class and main method.
- They must include a multi-line comment with the title of the practice problem AND the full instructions for the problem.
- All code filed under "solutions" should be solutions.
- Solutions should include the practice problem title AND full instructions at the top of the file (exact same comment as in the practice template file) and then a (possible) solution to the problem.
- All code filed under "practice" should be templates.
- The practice template and solution should have the same file name.
- Java: Make sure that you have the correct package statement as the first line of your code.
- Thoroughly test your solution. Make sure it works as intended.
- Try to break your program! Don’t just give input you know will work.
- Hundreds of students and ~50 teachers could potentially see and use your work. Please make sure that it works!
- Make sure that the problem is doable for the skill level of your students.
- Check Thinkific to see if the concepts that you need to solve the problem have been covered already.
- Be aware of how long your own class takes on other practice problems.
- Practice problems shouldn’t take several hours/days.
- If you are using data or practice problems from somewhere other than yourself, you MUST cite your sources.
- Providing a link to the original is usually sufficient if you found the problem online.
- If you found it in a book, cite the full title and author.
Note 1: If you choose option 1, we assume you know basic Git, e.g. committing, pushing, pulling, branching, merging, etc. If you want to learn the basic Git you need to contribute, we recommend watching this entire playlist.
Note 2: If you want an overview of the Pull Request (PR) workflow we are using, read these articles.
- Clone or fork the official C4T repository.
- All repositories can be found here: https://github.com/code4tomorrow
- How to Clone
- How to Fork
- Work on the practice problems locally.
- If you cloned the repo, make sure you create and checkout a new branch. DO NOT MAKE EDITS ON THE MASTER BRANCH.
- If you forked the repo, you’re free to work on the master branch or make your own branches (though that is kinda unnecessary).
- Git Branches Tutorial
- Push your local branch to remote.
- Make a pull request to merge your branch with the master branch of the official C4T repo.
- Follow the pull request template
- How to Create a Pull Request
- Monitor the status of your Pull Request on GitHub.
- It’s possible that the Curriculum Development team will Request Changes, in which case you will need to commit those changes before your PR will be approved and merged into the official master branch.
Thank you for following these guidelines and helping us build a problem base!