It is worth reading the start of the Concept Exercises file to familiarise yourself with Concept Exercises and why writing out Concepts is important.
To determine which Concept Exercises should be written for your language, you should first compile a list of your language's Concepts. There are various resources to use when compiling this list: books, (official) documentation, your own experiences and the concepts listed in this repository.
As many languages use the same Concepts (but possibly implemented differently), it can greatly help to look at what other languages have already done in this regard. See the C# concepts for an example.
It can also be helpful to group related Concepts. For example, the Classes, Polymorphism and Inheritance Concepts are all object-oriented Concepts, which can then be grouped as "Object-oriented concepts".
Filling out the Concepts will be iterative, it is hard to get this right immediately. While creating concepts exercises, you'll probably find missing concepts or perhaps want to split out concepts.
When starting this process, we strongly recommend you seek help from others who have defined Concepts, by asking questions on the #v3 channel on Slack.
Generally, only one new Concept should be introduced per Concept Exercise.
In order to keep the exercises interesting, maintainers may choose to introduce multiple trivial Concepts in one exercise.
A trivial Concept is one where we can reasonably assume that most programmers will quickly grasp it, due to prior familiarity, albeit with differing syntax. Examples might be basic number usage (+, -, *, etc.), or conditionals (if/else).
Every new Concept introduced, regardless of how trivial it may seem, must be explicitly mentioned in the exercise's introduction. Each mention should focus on how that Concept is applied in the given language, with links to learn more on the topic. If there is nothing special about it, a language-agnostic link is helpful.
All Concepts covered in a Concept Exercise must either be taught by it, or must be marked as a prerequisite in the config.json.
Concept Exercises should be named after their story/theme, not after its concept(s). The following rules apply to naming Concept Exercises:
- Use lowercase.
- Use kebab-case.
- Use the original name when forking an exercise without major changes.
Good examples:
tim-from-marketinglucians-luscious-lasagnacalculator-conundrum
Bad examples:
TIM-FROM-MARKETING: should use lowercase (i.e.tim-from-marketing)TimFromMarketing: should use use kebab-case (i.e.tim-from-marketing)floating-point-numbers: should not use a concept
When designing Concept Exercises, you'll find that the same basic Concepts will pop-up as prerequisites. As such, each track's first exercise should be an exercise that unlocks the basics concept, which aims to have the student become familiar with the basics of working in that language. The basics will differ between languages, but you can think of things like knowing how to define and call a function/method or how to define variables. For example, see this C# exercise.
To make the basics exercise the very first exercise, it must be the only exercise with no prerequisites. If an exercise has a prerequisite other than basics, you can omit the basics prerequisite.
Concept Exercise concepts (as used in the config.json file) should be named according to the following rules:
- Use lowercase.
- Use kebab-case.
- Don't use a hierarchy.
Good examples:
classesbit-manipulationfloating-point-numbers
Bad examples:
CLASSES: should use lowercase (i.e.classes)BitManipulation: should use use kebab-case (i.e.anonymous-functions)numbers-floating-point: should not use a hierarchical notation (usefloating-point-numbersinstead)numbers.floating-point: should not use a hierarchical notation (usefloating-point-numbersinstead)numbers/floating-point: should not use a hierarchical notation (usefloating-point-numbersinstead)