GSoC Coding Challenge Best Practice Guideline

From apertus wiki
Revision as of 19:32, 27 March 2019 by Sebastian (talk | contribs)
Jump to: navigation, search

1 Scope

The apertus° coding challenges are a great way to show us your programming skills. They are also a perfect test-balloon to see how collaboration and communication with your potential future mentor works out.

We consider your coding challenge submission equally as important as your proposal. This document is intended to help you understand what we are looking for.

If you are still learning how to program Google Summer of Code is the wrong program for you. We expect you to already have substantial knowledge of Linux, programming, compiling, debugging etc. and want to work with you to expand your horizon. Consider Google Code In (https://codein.withgoogle.com) if you want to learn how to program.

Using or improving upon existing code is permitted but, in the event that code authored by somebody else is used, the code's original author must be credited. This is 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

We would like to see the best in you so doing one task (where you can choose from several challenges) really well is much better than doing all of them 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 we 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 you follow coding language matching formatting conventions or object oriented programing design pattern (only if the challenge is object oriented)