Difference between revisions of "GSoC Coding Challenge Best Practice Guideline"
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
=Scope= | =Scope= | ||
The apertus° coding challenges are a great way to show us your programming skills. They serve as a perfect test-case to see how collaboration and communication between students and mentors works out. It's also an opportunity for you to experience how the program will be if your application is accepted. | |||
Your coding challenge submission and your proposal are considered equally important. This guideline is intended to help you understand what is being looked for. | |||
Using or improving upon existing code is permitted but | If you're still learning how to program then Google Summer of Code is the wrong program for you. Already having a substantial knowledge of Linux, programming, compiling, debugging etc. is generally an essential prerequisite for consideration. Possibly see Google Code In (https://codein.withgoogle.com) if you want to learn programming basics. | ||
Using or improving upon existing code is permitted, but in the event that code authored by somebody else is used, then the code's original author must be credited (common practice in the open source world). There is no shame in building upon the work of others - just make sure you understand what the code is doing and give credit where appropriate. | |||
=Quality over Quantity= | =Quality over Quantity= | ||
Our community's participation in the GSoC program is all about helping you to get the best out of yourself. For this reason selecting one task (from a choice of several challenges) and developing it very well is much better than developing many challenge tasks in a sloppy way. When you select which challenge(s) to solve, consider which of them would match the area of your proposal/idea best. | |||
'''What mentors like:''' | |||
* Clean and consistent formatting. | |||
* | * Variables and functions, etc. with self explanatory names. | ||
* | * Comments which explain what your code is doing. | ||
* | * Easily readable and self explaining code. | ||
* | * Seeing that you understand your code. | ||
* | * Seeing you incorporate mentor suggestions and feedback. | ||
* | * Seeing that you follow coding language matching formatting conventions or object oriented programming design pattern (only if the challenge is object oriented). | ||
* | |||
Latest revision as of 19:32, 29 March 2019
1 Scope
The apertus° coding challenges are a great way to show us your programming skills. They serve as a perfect test-case to see how collaboration and communication between students and mentors works out. It's also an opportunity for you to experience how the program will be if your application is accepted.
Your coding challenge submission and your proposal are considered equally important. This guideline is intended to help you understand what is being looked for.
If you're still learning how to program then Google Summer of Code is the wrong program for you. Already having a substantial knowledge of Linux, programming, compiling, debugging etc. is generally an essential prerequisite for consideration. Possibly see Google Code In (https://codein.withgoogle.com) if you want to learn programming basics.
Using or improving upon existing code is permitted, but in the event that code authored by somebody else is used, then the code's original author must be credited (common practice in the open source world). There is no shame in building upon the work of others - just make sure you understand what the code is doing and give credit where appropriate.
2 Quality over Quantity
Our community's participation in the GSoC program is all about helping you to get the best out of yourself. For this reason selecting one task (from a choice of several challenges) and developing it very well is much better than developing many challenge tasks in a sloppy way. When you select which challenge(s) to solve, consider which of them would match the area of your proposal/idea best.
What mentors like:
- Clean and consistent formatting.
- Variables and functions, etc. with self explanatory names.
- Comments which explain what your code is doing.
- Easily readable and self explaining code.
- Seeing that you understand your code.
- Seeing you incorporate mentor suggestions and feedback.
- Seeing that you follow coding language matching formatting conventions or object oriented programming design pattern (only if the challenge is object oriented).