Praxisübungen

Practice Exercises sind Übungen, mit denen Lernende ein beliebiges Problem lösen können, mit dem Ziel, dass sie die Konzepte anwenden, die sie bisher gelernt haben.

Du möchtest deine erste Practice Exercise zu einem Track hinzufügen? Schau in die Dokumentation zum Hinzufügen einer Practice Exercise oder sieh dir unser Walkthrough-Video an 👇

Note

Du kannst eine neue Practice Exercise schnell anlegen, indem du die folgenden Befehle im Stammverzeichnis des Tracks ausführst:

bin/fetch-configlet
bin/configlet create --practice-exercise <slug>

Weitere Informationen findest du in der configlet create-Dokumentation

Metadaten

Die Metadaten einer Practice Exercise werden im Schlüssel exercises.practice in der config.json-Datei definiert. Die Metadaten legen unter anderem die UUID und den Slug der Übung fest.

Beispiel

{
  "exercises": {
    "practice": [
      {
        "uuid": "8ba15933-29a2-49b1-a9ce-70474bad3007",
        "slug": "leap",
        "name": "Leap",
        "practices": ["if-statements", "numbers", "operator-precedence"],
        "prerequisites": ["if-statements", "numbers"],
        "difficulty": 1
      }
    ]
  }
}

`practices`

Der Schlüssel practices sollte die Slugs der Konzepte auflisten, die diese Practice Exercise aktiv üben lässt.

Diese erscheinen in der Benutzeroberfläche als „Übe dieses Konzept in: TwoFer, Leap, usw."
Versuche, 3 bis 8 Übungen auszuwählen, die ein Konzept üben.
Versuche, mindestens zwei Übungen auszuwählen, mit denen man die Grundlagen eines Konzepts üben kann.
Manche Konzepte sind sehr verbreitet (zum Beispiel strings). In solchen Fällen empfehlen wir, ein paar gute Übungen auszuwählen, die die Lernenden auf interessante Weise zum Nachdenken über diese Konzepte bringen. Gute Beispiele sind etwa Übungen, die UTF-8, String-Verkettung, das Aufzählen von Zeichen und Ähnliches erfordern.

`prerequisites`

Der Schlüssel prerequisites listet die Konzepte auf, die ein Lernender abgeschlossen haben muss, um auf diese Practice Exercise zugreifen zu können.

Diese erscheinen in der Benutzeroberfläche als „Lerne Strings, um TwoFer freizuschalten"
Er sollte alle Konzepte enthalten, die ein Lernender abgedeckt haben muss, um die Übung auf mindestens eine idiomatische Weise lösen zu können. Für die TwoFer-Übung in Ruby könnten die Voraussetzungen zum Beispiel strings, optional-params und implicit-return umfassen.
Bei Übungen, die sich mit alternativen Konzepten lösen lassen (zum Beispiel eine Übung, die sich mit loops oder recursion lösen lässt), sollte der Maintainer den einen Ansatz wählen, mit dem er die Übung freischalten möchte, und dabei den Weg des Lernenden durch den Track berücksichtigen. Im Beispiel mit Loops/Rekursion könnte er denken, dass diese Übung eine gute frühe Übung für loops ist, oder er möchte sie lieber später einsetzen, um Rekursion zu lehren. Er kann auch einen Analyzer einsetzen, um den Lernenden zu einem alternativen Ansatz anzuregen: „Gute Arbeit, das mit Schleifen zu lösen. Vielleicht möchtest du es auch einmal mit Rekursion versuchen."

Dateien

Jede Practice Exercise hat ihr eigenes Verzeichnis im exercises/practice-Verzeichnis des Tracks. Der Name des Verzeichnisses der Practice Exercise muss mit der Eigenschaft slug der Practice Exercise übereinstimmen, wie sie in der config.json-Datei definiert ist.

Eine Practice Exercise hat vier Arten von Dateien:

Dokumentationsdateien

Diese Dateien werden dem Lernenden gezeigt, um die Übung zu erklären.

.docs/introduction.md: führt in den Rahmen und Hintergrund der Übung ein (optional)
.docs/introduction.append.md: zusätzlicher Einführungstext, der nach der vorhandenen Einführung angehängt wird (optional)
.docs/instructions.md: enthält die Aufgabenstellung für die Übung (erforderlich)
.docs/instructions.append.md: zusätzlicher Einführungstext, der nach der vorhandenen Aufgabenstellung angehängt wird (optional)
.docs/hints.md: enthält Hinweise für Lernende, die ihnen helfen, wenn sie bei der Übung nicht weiterkommen (optional)

Metadatendateien

Diese Dateien werden dem Lernenden nicht gezeigt, sondern dienen dazu, die Metadaten der Übung zu definieren.

.meta/config.json: enthält Meta-Informationen zur Übung (erforderlich)
.meta/design.md: beschreibt das Design der Übung (optional)
.meta/tests.toml: enthält Informationen darüber, welche Tests implementiert sind (optional)

Ansatz-Dateien

Diese Dateien beschreiben Ansätze für die Übung.

.approaches/introduction.md: Einführung in die gängigsten Ansätze für die Übung (optional)
.approaches/config.json: Metadaten für die Ansätze (optional)
.approaches/<approach-slug>/content.md: Beschreibung des Ansatzes (optional)
.approaches/<approach-slug>/snippet.txt: Snippet, das den Ansatz vorstellt (optional)

Artikeldateien

Diese Dateien beschreiben Artikel für die Übung.

.articles/config.json: Metadaten für die Artikel (optional)
.articles/<article-slug>/content.md: Beschreibung des Artikels (optional)
.articles/<article-slug>/snippet.md: Snippet, das den Artikel vorstellt (optional)

Übungsdateien

Die sprachspezifischen Dateien, wie die Implementierungs- und die Testdateien. Die Namen dieser Dateien sind Track-spezifisch.

Test-Suite: überprüft die Korrektheit einer Lösung.
Stub-Implementierung: bietet Lernenden einen Ausgangspunkt.
Beispielimplementierung: bietet eine Beispielimplementierung, die alle Tests besteht.
Zusätzliche Dateien: stellen sicher, dass die Tests ausgeführt werden können.

Beispiel

exercises
└── practice
    └── isogram
        ├── .approaches
        |   ├── for-loop
        |   |   ├── content.md
        |   |   └── snippet.txt
        |   ├── config.json
        |   └── introduction.md
        ├── .articles
        |   ├── performance
        |   |   ├── content.md
        |   |   └── snippet.md
        |   └── config.json
        ├── .docs
        |   ├── introduction.md
        |   ├── instructions.md
        |   └── hints.md
        ├── .meta
        |   ├── config.json
        |   ├── design.md
        |   ├── tests.toml
        |   └── Example.cs (example implementation)
        ├── Isogram.cs (stub implementation)
        └── IsogramTests.cs (tests)

Datei: `.docs/introduction.md`

Zweck: Führt den Lernenden in den Rahmen und Hintergrund der Übung ein.

Vorkommen: Erforderlich, wenn die Übung eine Problem-Specifications-Übung mit einer introduction.md-Datei implementiert

Wenn die Übung eine Problem-Specifications-Übung implementiert, sollte der Inhalt dieser Datei mit der Datei introduction.md der Problem-Specifications-Übung übereinstimmen. configlet kann den Inhalt dieser Datei automatisch synchronisieren.

Wenn die Übung nicht auf einer Problem-Specifications-Übung basiert, beachte Folgendes:

Uns ist sehr wichtig, dass die Inhalte von Exercism für alle sicher sind, deshalb entscheiden wir bei der Frage, ob eine Geschichte angemessen ist oder nicht, lieber vorsichtig. Wir achten zwar darauf, was wir zusammenführen, aber uns ist klar, dass man schwer erkennen kann, was als problematisch wahrgenommen werden könnte. Deshalb gehen wir immer davon aus, dass du in guter Absicht handelst, und geben unser Bestes, um Probleme im Review auf nicht konfrontative Weise anzusprechen. Wenn du eine Geschichte mit uns abklären möchtest, erwähne bitte @exercism/leadership, dann schauen wir sie uns gemeinsam an. Hier sind einige Leitlinien:

Achte darauf, dass die Geschichte einladend ist und von allen verstanden werden kann. Wenn die Geschichte Insiderwitze oder regionalen Slang enthält, denk über alternative Formulierungen nach.
Versuche, Beispiele zu schreiben, die alle einschließen. Denk zum Beispiel darüber nach, Namen aus anderen Kulturen und gemischte Geschlechter zu verwenden.
Frag dich, ob du persönlich jemanden kennst, der sich durch die Geschichte angegriffen fühlen würde. Wenn ja, ändere sie lieber, um das zu vermeiden.

Beispiel

# Introduction

Bob is a lackadaisical teenager. In conversation, his responses are very limited.

Datei: `.docs/introduction.append.md`

Zweck: Zusätzlicher Einführungstext, der nach der vorhandenen Einführung angehängt wird.

Vorkommen: Optional

In manchen (seltenen) Fällen möchtest du die Datei introduction.md der Übung erweitern, zum Beispiel wenn die Übung Tests implementiert hat, die von der vorhandenen Aufgabenstellung nicht abgedeckt werden.

Ein Track, in dem Bob keine Nicht-ASCII-Nachrichten unterstützen soll, könnte Folgendes hinzufügen:

# Introduction append

## Note

As part of his teenage rebellion, Bob has decided to only communicate using ASCII.

Append-Dateien sollten mit einer H1-Überschrift beginnen. Diese Überschrift wird nicht angezeigt, sollte aber trotzdem vorhanden sein. Auf die H1-Überschrift folgt oft eine H2-Überschrift, die hilft, den generischen Inhalt vom Track-spezifischen Inhalt zu trennen.

Datei: `.docs/instructions.md`

Zweck: Die Aufgabenstellung für die Übung bereitstellen.

Vorkommen: Erforderlich

Wenn die Übung eine Problem-Specifications-Übung implementiert, sollte der Inhalt dieser Datei mit der Datei instructions.md der Problem-Specifications-Übung übereinstimmen (oder mit der Datei description.md, wenn es keine Datei instructions.md gibt). configlet kann den Inhalt dieser Datei automatisch synchronisieren.

Wenn die Übung nicht auf einer Problem-Specifications-Übung basiert, beachte Folgendes:

Achte darauf, dass die Geschichte einladend ist und von allen verstanden werden kann. Wenn die Geschichte Insiderwitze oder regionalen Slang enthält, denk über alternative Formulierungen nach.
Versuche, Beispiele zu schreiben, die alle einschließen. Denk zum Beispiel darüber nach, Namen aus anderen Kulturen und gemischte Geschlechter zu verwenden.
Frag dich, ob du persönlich jemanden kennst, der sich durch die Geschichte angegriffen fühlen würde. Wenn ja, ändere sie lieber, um das zu vermeiden.

Beispiel

# Instructions

Bob answers 'Sure.' if you ask him a question, such as "How are you?".

He answers 'Whoa, chill out!' if you YELL AT HIM (in all capitals).

He answers 'Calm down, I know what I'm doing!' if you yell a question at him.

He says 'Fine. Be that way!' if you address him without actually saying anything.

He answers 'Whatever.' to anything else.

Datei: `.docs/instructions.append.md`

Zweck: Zusätzlicher Anweisungstext, der nach der vorhandenen Aufgabenstellung angehängt wird.

Vorkommen: Optional

In manchen (seltenen) Fällen möchtest du die Datei instructions.md der Übung erweitern, zum Beispiel wenn die Übung Tests implementiert hat, die von der vorhandenen Aufgabenstellung nicht abgedeckt werden.

# Instructions append

## Note

Bob's conversational partner is a purist when it comes to written communication and always follows normal rules regarding sentence punctuation in English.

Datei: `.docs/hints.md`

Zweck: Hinweise für Lernende, die ihnen helfen, wenn sie bei einer Übung nicht weiterkommen.

Vorkommen: Optional

Wenn der Lernende nicht weiterkommt, kann er auf eine Schaltfläche klicken, um einen Hinweis anzufordern, der den relevanten Teil der Datei anzeigt.
Hinweise sollten als Aufzählungspunkte unter Überschriften stehen.
Die Hinweise sollten ausreichen, um fast jeden Lernenden wieder auf den Weg zu bringen.
Die Hinweise sollten die Lösung nicht vorgeben, sondern auf eine Ressource verweisen, die die Lösung beschreibt (zum Beispiel einen Link zur Dokumentation der zu verwendenden Funktion).
Die Hinweise dürfen Codebeispiele verwenden, um Konzepte zu erklären, aber nicht, um die Lösung zu umreißen. In einer Listen-Übung könnte zum Beispiel ein Snippet zeigen, wie eine bestimmte Listenfunktion funktioniert, aber nicht so, dass man es direkt in die Lösung kopieren kann.
Die Hinweise müssen als Markdown-Liste unter einer Überschrift ## General stehen.
Wenn es keine Hinweise gibt, sollte die Überschrift weggelassen werden.

Das Anzeigen von Hinweisen ist kein „empfohlener" Weg, und wir raten (sanft) davon ab, es zu nutzen, es sei denn, der Lernende kommt ohne sie nicht weiter. Bedenke deshalb, dass der Lernende, der sie liest, ein wenig verwirrt oder überfordert und vielleicht frustriert sein wird.

Beispiel

## General

- There are many [built-in methods][integers] to simplify working with integers.

[integers]: https://ruby-doc.org/core-2.7.0/Integer.html

Datei: .meta/design.md

Zweck: Das Design der Übung beschreiben.

Vorkommen: Optional

Diese Datei enthält Informationen zum Design der Übung, darunter das Ziel, die Lernziele, was nicht gelehrt werden soll und mehr.

Sie existiert, um zukünftige Maintainer oder Contributors über den Umfang und die Grenzen einer Übung zu informieren und so dem natürlichen Trend entgegenzuwirken, Übungen mit der Zeit komplexer zu machen.

Beispiel

# Design

## Goal

The goal of this exercise is help students practice how to work with strings.

## Notes

This exercise does not contain any error handling tests.

Datei: `.meta/config.json`

Zweck: Enthält Meta-Informationen zur Übung.

Vorkommen: Erforderlich

Diese Datei enthält Meta-Informationen zur Übung:

authors: Der/die GitHub-Benutzernamen des Autors bzw. der Autoren der Übung (optional)
- Einschließlich Reviewer, wenn ihre Reviews die Übung wesentlich verändern (so sehr, dass es sich anfühlt, als hättet ihr das gemeinsam erreicht)
contributors: Der/die GitHub-Benutzernamen des Contributors bzw. der Contributors der Übung (optional)
- Einschließlich Reviewer, wenn ihre Reviews aussagekräftig, umsetzbar oder umgesetzt sind.
files: Die Speicherorte der in dieser Übung verwendeten Dateien, relativ zum Verzeichnis der Übung (erforderlich)
- solution: die Stub-Implementierungsdatei(en) (erforderlich)
- test: die Testdatei(en) (erforderlich)
- example: die Beispielimplementierungsdatei(en) (erforderlich)
- editor: zusätzliche Dateien, die im Editor schreibgeschützt angezeigt werden (optional)
- invalidator: Dateien, die bei Änderung dazu führen, dass eine Lösung veraltet (optional)
language_versions Anforderungen an die Sprachversion (optional)
blurb: Eine kurze Beschreibung dieser Übung. Die Länge muss <= 350 sein. Markdown wird nicht unterstützt (erforderlich)
source: Die Quelle, auf der diese Übung basiert (optional)
source_url: Die URL der Quelle, auf der diese Übung basiert (optional)
test_runner: Gibt an, ob Lösungen dieser Übung im Test-Runner getestet werden sollen. Standardwert ist true, wenn nichts angegeben ist. (optional)
representer: Meta-Informationen dazu, wie der Representer diese Datei verarbeitet (optional)
- version: Eine Ganzzahl für die Version des Representers, die für die Übung verwendet werden soll (erforderlich, wenn der übergeordnete Schlüssel vorhanden ist)
icon: Der Slug des Icons (siehe die vollständige Liste der Icons). Wenn nichts angegeben ist, wird der Slug der Übung verwendet (optional)
custom: Beliebige übungsspezifische, nicht standardmäßige Daten. Kann verwendet werden, um das Verhalten der Track-Tools pro Übung anzupassen (optional)

Wenn jemand sowohl Autor als auch Contributor ist, führe diese Person nur als Autor auf.

Beispiel

{
  "authors": ["FSharpForever"],
  "files": {
    "solution": ["Bob.fs"],
    "test": ["BobTests.fs"],
    "example": [".meta/Example.fs"]
  },
  "blurb": "Bob is a lackadaisical teenager. In conversation, his responses are very limited"
}

Beachte:

Die Reihenfolge von Autoren und Contributors spielt keine Rolle und hat keine Bedeutung.
language_versions ist ein freier String, den Tracks nach Belieben verwenden und interpretieren können.

Datei: .meta/tests.toml

Zweck: Enthält Informationen darüber, welche Tests implementiert sind.

Vorkommen: Optional

Diese Datei enthält Informationen darüber, welche Tests implementiert werden, sofern die Übung Tests in ihrer Datei canonical-data.json im problem-specifications-Repo definiert hat.

Sie hilft Maintainern, den Überblick zu behalten, welche Tests implementiert sind, und (optional) zu dokumentieren, warum ein bestimmter Test nicht implementiert ist. Außerdem kann sie verwendet werden, um nicht implementierte Tests zu erkennen.

Das Tool configlet aktualisiert bzw. synchronisiert diese Datei über den Befehl configlet sync mit den Daten im problem-specifications-Repo. Beim Synchronisieren fragt configlet für jeden nicht implementierten Test, ob dieser Test aufgenommen werden soll oder nicht.

Beispiel

# This is an auto-generated file.
#
# Regenerating this file via `configlet sync` will:
# - Recreate every `description` key/value pair
# - Recreate every `reimplements` key/value pair, where they exist in problem-specifications
# - Remove any `include = true` key/value pair (an omitted `include` key implies inclusion)
# - Preserve any other key/value pair
#
# As user-added comments (using the # character) will be removed when this file
# is regenerated, comments can be added via a `comment` key.

[3e5c30a8-87e2-4845-a815-a49671ade970]
description = "empty strand"

[a0ea42a6-06d9-4ac6-828c-7ccaccf98fec]
description = "can count one nucleotide in single-character input"

[eca0d565-ed8c-43e7-9033-6cefbf5115b5]
description = "strand with repeated nucleotide"

[40a45eac-c83f-4740-901a-20b22d15a39f]
description = "strand with multiple nucleotides"

[b4c47851-ee9e-4b0a-be70-a86e343bd851]
description = "strand with invalid nucleotides"
include = false
comment = "error handling omitted on purpose"

Datei: `.approaches/introduction.md`

Zweck: Einführung in die gängigsten Ansätze für die Übung

Vorkommen: Optional

Diese Datei beschreibt die gängigsten Ansätze für die Übung. Weitere Informationen dazu, was in diese Datei gehört, findest du in der Dokumentation.

Beispiel

# Introduction

The key to this exercise is to deal with C# strings being immutable, which means that a `string`'s value cannot be changed.
Therefore, to reverse a string you'll need to create a _new_ `string`.

## Using LINQ

```csharp
public static string Reverse(string input)
{
    return new string(input.Reverse().ToArray());
}
```

For more information, check the [LINQ approach][approach-linq].

## Which approach to use?

If readability is your primary concern (and it usually should be), the LINQ-based approach is hard to beat.

Datei: `.approaches/config.json`

Zweck: Metadaten für die Ansätze

Vorkommen: Optional (erforderlich, wenn eine Ansatz-Einführung oder ein Ansatz vorhanden ist)

Diese Datei enthält Meta-Informationen zu den Ansätzen der Übung:

introduction: Der/die GitHub-Benutzernamen des Autors bzw. der Autoren der Ansatz-Einführung der Übung (optional)
- authors: Der/die GitHub-Benutzernamen des Autors bzw. der Autoren der Ansatz-Einführung der Übung (erforderlich)
  - Einschließlich Reviewer, wenn ihre Reviews die Ansatz-Einführung der Übung wesentlich verändern (so sehr, dass es sich anfühlt, als hättet ihr das gemeinsam erreicht)
- contributors: Der/die GitHub-Benutzernamen des Contributors bzw. der Contributors der Ansatz-Einführung der Übung (optional)
  - Einschließlich Reviewer, wenn ihre Reviews aussagekräftig, umsetzbar oder umgesetzt sind.
approaches: Ein Array, das die detaillierten Ansätze auflistet (optional)
- uuid: eine V4-UUID, die den Ansatz eindeutig identifiziert. Die UUID muss sowohl innerhalb des Tracks als auch über alle Tracks hinweg eindeutig sein und darf sich nie ändern
- slug: der Slug des Ansatzes, ein String in Kleinbuchstaben im Kebab-Case. Der Slug muss über alle Ansatz-Slugs innerhalb des Tracks hinweg eindeutig sein. Seine Länge muss <= 255 sein.
- title: der Titel des Ansatzes. Seine Länge muss <= 255 sein.
- blurb: Eine kurze Beschreibung dieses Ansatzes. Die Länge muss <= 350 sein. Markdown wird nicht unterstützt (erforderlich)
- authors: Der/die GitHub-Benutzernamen des Autors bzw. der Autoren des Übungsansatzes (erforderlich)
  - Einschließlich Reviewer, wenn ihre Reviews den Übungsansatz wesentlich verändern (so sehr, dass es sich anfühlt, als hättet ihr das gemeinsam erreicht)
- contributors: Der/die GitHub-Benutzernamen des Contributors bzw. der Contributors des Übungsansatzes (optional)
  - Einschließlich Reviewer, wenn ihre Reviews aussagekräftig, umsetzbar oder umgesetzt sind.
- tags: Legt die Bedingungen fest, unter denen eine eingereichte Lösung mit einem Ansatz verknüpft wird. (optional)
  - all: Ein Array von Tags, die alle auf einer eingereichten Lösung vorhanden sein müssen (optional, es sei denn, any hat keine Elemente)
  - any: Ein Array von Tags, von denen mindestens einer auf einer eingereichten Lösung vorhanden sein muss (optional, es sei denn, all hat keine Elemente)
  - not: Keiner der Tags darf auf einer eingereichten Lösung vorhanden sein (optional)

Beispiel

{
  "introduction": {
    "authors": ["erikschierboom"]
  },
  "approaches": [
    {
      "uuid": "448fb2b4-18ab-4e55-aa54-ad4ed6d5f7f6",
      "slug": "span",
      "title": "Use Span<T>",
      "blurb": "Use Span<T> to efficiently reverse a string.",
      "authors": ["erikschierboom"]
    }
  ]
}

Datei: `.approaches/<approach-slug>/content.md`

Zweck: Detaillierte Beschreibung des Ansatzes

Vorkommen: Optional (erforderlich für Ansätze)

Diese Datei enthält eine detaillierte Beschreibung des Ansatzes. Weitere Informationen dazu, was in diese Datei gehört, findest du in der Dokumentation.

Beispiel

# Span

```csharp
Span<char> chars = stackalloc char[input.Length];
for (var i = 0; i < input.Length; i++)
{
    chars[input.Length - 1 - i] = input[i];
}
return new string(chars);
```

This `Span<T>` approach uses a `for` loop.

Datei: `.approaches/<approach-slug>/snippet.txt`

Zweck: Snippet, das den Ansatz vorstellt

Vorkommen: Optional (erforderlich für Ansätze)

Diese Datei enthält ein kleines Snippet, das den Ansatz vorstellt. Das Snippet wird auf der Dig-Deeper-Seite einer Übung angezeigt.

Die Anzahl der Zeilen muss <= 8 sein.

Weitere Informationen dazu, was in diese Datei gehört, findest du in der Dokumentation.

Beispiel

Span<char> chars = stackalloc char[input.Length];
for (var i = 0; i < input.Length; i++)
{
    chars[input.Length - 1 - i] = input[i];
}
return new string(chars);

Datei: `.article/config.json`

Zweck: Metadaten für die Artikel

Vorkommen: Optional (erforderlich, wenn ein Artikel vorhanden ist)

Diese Datei enthält Meta-Informationen zu den Artikeln der Übung:

articles: Ein Array, das die detaillierten Artikel auflistet (optional)
- uuid: eine V4-UUID, die den Artikel eindeutig identifiziert. Die UUID muss sowohl innerhalb des Tracks als auch über alle Tracks hinweg eindeutig sein und darf sich nie ändern
- slug: der Slug des Artikels, ein String in Kleinbuchstaben im Kebab-Case. Der Slug muss über alle Artikel-Slugs innerhalb des Tracks hinweg eindeutig sein. Seine Länge muss <= 255 sein.
- title: der Titel des Artikels. Seine Länge muss <= 255 sein.
- blurb: Eine kurze Beschreibung dieses Artikels. Die Länge muss <= 350 sein. Markdown wird nicht unterstützt (erforderlich)
- authors: Der/die GitHub-Benutzernamen des Autors bzw. der Autoren des Übungsartikels (erforderlich)
  - Einschließlich Reviewer, wenn ihre Reviews den Übungsartikel wesentlich verändern (so sehr, dass es sich anfühlt, als hättet ihr das gemeinsam erreicht)
- contributors: Der/die GitHub-Benutzernamen des Contributors bzw. der Contributors des Übungsartikels (optional)
  - Einschließlich Reviewer, wenn ihre Reviews aussagekräftig, umsetzbar oder umgesetzt sind.

Beispiel

{
  "articles": [
    {
      "uuid": "6db71962-62d5-448b-a980-c20ae41013ed",
      "slug": "performance",
      "title": "Optimizing performance",
      "blurb": "Explore how to most efficiently reverse a string and what the trade-offs are.",
      "authors": ["erikschierboom"]
    }
  ]
}

Datei: `.articles/<article-slug>/content.md`

Zweck: Detaillierte Beschreibung des Ansatzes

Vorkommen: Optional (erforderlich für Ansätze)

Diese Datei enthält eine detaillierte Beschreibung des Ansatzes. Weitere Informationen dazu, was in diese Datei gehört, findest du in der Dokumentation.

Beispiel

# Performance

In this document, we'll find out which approach is the most performant one.

## Benchmark results

| Method |      Mean |     Error |    StdDev |    Median | Allocated |
| -----: | --------: | --------: | --------: | --------: | --------: |
|   Linq | 29.133 ns | 0.5865 ns | 0.5486 ns | 28.984 ns |      80 B |
|  Array |  4.806 ns | 0.4999 ns | 1.4739 ns |  3.967 ns |         - |

Datei: `.articles/<article-slug>/snippet.txt`

Zweck: Snippet, das den Ansatz vorstellt

Vorkommen: Optional (erforderlich für Artikel)

Diese Datei enthält ein kleines Snippet, das den Artikel vorstellt. Das Snippet wird auf der Dig-Deeper-Seite einer Übung angezeigt.

Die Anzahl der Zeilen muss <= 8 sein.

Weitere Informationen dazu, was in diese Datei gehört, findest du in der Dokumentation.

Beispiel

| Method |      Mean | Allocated |
| -----: | --------: | --------: |
|   Linq | 29.133 ns |      80 B |
|  Array |  4.806 ns |         - |

Datei: Stub-Implementierung

Zweck: Lernenden einen Ausgangspunkt bieten.

Vorkommen: Erforderlich

Gestalte den Stub so, dass der Lernende weiß, wo er Code hinzufügen muss.
Bei kompilierten Sprachen solltest du darauf achten, dass der Code kompilierbar ist, denn Compilermeldungen sind für Lernende, die neu in der Sprache sind, manchmal schwer zu verstehen.
Der Code sollte so einfach wie möglich sein.
Verwende nur Sprachfunktionen, die durch die Voraussetzungen (und deren Voraussetzungen und so weiter) eingeführt werden.
Die Stub-Datei wird dem Lernenden beim Programmieren im Browser angezeigt und bei Verwendung der Kommandozeile in sein Dateisystem heruntergeladen.
Die relativen Pfade zur Stub-Implementierungsdatei bzw. zu den Stub-Implementierungsdateien müssen im Schlüssel "files.solution" der Datei .meta/config.json angegeben werden.

Beispiel

using System;

public static class Isogram
{
    public static bool IsIsogram(string word)
    {
        throw new NotImplementedException("You need to implement this function.");
    }
}

Datei: Tests

Zweck: Die Korrektheit einer Lösung überprüfen.

Vorkommen: Erforderlich

Der Code sollte so einfach wie möglich sein.
Verwende nur Sprachfunktionen, die durch die Voraussetzungen der Übung (und deren Voraussetzungen und so weiter) eingeführt werden.
Die Testdatei wird dem Lernenden beim Programmieren im Browser angezeigt und bei Verwendung der Kommandozeile in sein Dateisystem heruntergeladen.
Exercism befürwortet, dass Practice Exercises über Test Driven Development abgeschlossen werden. Dafür gibt es zwei Möglichkeiten:
- Der Test-Runner muss die Tests in der in der Datei definierten Reihenfolge ausführen UND die Test-Suite muss beim ersten Fehler abbrechen; oder
- Alle Tests außer dem ersten sollten standardmäßig übersprungen werden.
Die relativen Pfade zur Testdatei bzw. zu den Testdateien müssen im Schlüssel "files.test" der Datei .meta/config.json angegeben werden.

Beispiel

using Xunit;

public class IsogramTest
{
    [Fact]
    public void Empty_string() =>
        Assert.True(Isogram.IsIsogram(""));

    [Fact(Skip = "Remove this Skip property to run this test")]
    public void Isogram_with_only_lower_case_characters() =>
        Assert.True(Isogram.IsIsogram("isogram"));

    [Fact(Skip = "Remove this Skip property to run this test")]
    public void Word_with_one_duplicated_character() =>
        Assert.False(Isogram.IsIsogram("eleven"));
}

Datei: Beispielimplementierung

Zweck: Eine Beispielimplementierung bereitstellen, die alle Tests besteht.

Vorkommen: Erforderlich

Diese Implementierung wird verwendet, um zu überprüfen, dass es eine Implementierung gibt, die die Tests bestanden hat. Sie ist bewusst nicht der Zielcode, auf den ein Lernender hinarbeiten soll.
Jeder Track sollte in seiner Continuous-Integration-Umgebung überprüfen, dass die Beispielimplementierung die Tests besteht.
Mentoren wird dieser Code nicht angezeigt.
Die Beispieldatei wird dem Lernenden beim Programmieren im Browser nicht angezeigt und bei Verwendung der Kommandozeile nicht in sein Dateisystem heruntergeladen.
Die relativen Pfade zur Beispielimplementierungsdatei bzw. zu den Beispielimplementierungsdateien müssen im Schlüssel "files.example" der Datei .meta/config.json angegeben werden.

Beispiel

using System.Linq;

public static class Isogram
{
    public static bool IsIsogram(string word)
    {
        var lowerCaseLetters = word.ToLower().Where(char.IsLetter).ToList();
        return lowerCaseLetters.Distinct().Count() == lowerCaseLetters.Count;
    }
}

Datei: Zusätzliche Dateien

Zweck: Zusätzliche Projekt-, Build- oder Hilfsdateien, die erforderlich sind, damit die Tests ausgeführt werden können.

Vorkommen: Erforderlich, wenn die Standarddateien nicht ausreichen, um die Tests auszuführen

Manche Sprachen benötigen zusätzliche Dateien, damit die Tests ausgeführt werden können. Beispiele dafür sind die Projektdateien von C# und die package.json-Dateien von Node, ohne die die Tests nicht ausgeführt werden können.

Gemeinsam genutzte Dateien

Manche Dateien sind nicht spezifisch für einzelne Übungen, sondern gelten für alle Übungen. Weitere Informationen findest du in der Dokumentation.

Darstellung

Es gibt einen Unterschied darin, wie die Übungsdokumentation dem Lernenden angezeigt wird, je nachdem, ob er den Browser-Editor oder die Kommandozeile verwendet. Weitere Informationen findest du in diesem Dokument.

Icon

Jede Übung hat ein zugehöriges Icon. Standardmäßig wird das Icon angezeigt, dessen Name mit dem Slug der Übung übereinstimmt. Man kann das überschreiben, indem man die Eigenschaft icon in der Datei .meta/config.json der Übung angibt.

Wenn du eine Übung anhand der problem-specifications-Metadaten implementierst, gibt es für diese Übung wahrscheinlich schon ein Icon. Wenn nicht, öffne bitte ein Issue im website-icons-Repository.

Sprach-Tracks

Mit Jiki programmieren lernen

Deine Reise

Deine FavoritenNeu

Exercism-Vorteile

Community-Videos

Reihe kurzer Einführungen

Interviews und Geschichten

Discord

Forum

Erste Schritte

Mentoring

Dokumentation

Mitwirkende

ÜbersetzerNeu

Spenden

Über Exercism

Unsere Wirkung

GitHub SyncerNeu

Insiders

Praxisübungen

Metadaten

Beispiel

practices

prerequisites

Dateien

Dokumentationsdateien

Metadatendateien

Ansatz-Dateien

Artikeldateien

Übungsdateien

Beispiel

Datei: .docs/introduction.md

Beispiel

Datei: .docs/introduction.append.md

Datei: .docs/instructions.md

Beispiel

Datei: .docs/instructions.append.md

Datei: .docs/hints.md

Beispiel

Datei: .meta/design.md

Beispiel

Datei: .meta/config.json

Beispiel

Datei: .meta/tests.toml

Beispiel

Datei: .approaches/introduction.md

Beispiel

Datei: .approaches/config.json

Beispiel

Datei: .approaches/<approach-slug>/content.md

Beispiel

Datei: .approaches/<approach-slug>/snippet.txt

Beispiel

Datei: .article/config.json

Beispiel

Datei: .articles/<article-slug>/content.md

Beispiel

Datei: .articles/<article-slug>/snippet.txt

Beispiel

Datei: Stub-Implementierung

Beispiel

Datei: Tests

Beispiel

Datei: Beispielimplementierung

Beispiel

Datei: Zusätzliche Dateien

Gemeinsam genutzte Dateien

Darstellung

Icon

`practices`

`prerequisites`

Datei: `.docs/introduction.md`

Datei: `.docs/introduction.append.md`

Datei: `.docs/instructions.md`

Datei: `.docs/instructions.append.md`

Datei: `.docs/hints.md`

Datei: `.meta/config.json`

Datei: `.approaches/introduction.md`

Datei: `.approaches/config.json`

Datei: `.approaches/<approach-slug>/content.md`

Datei: `.approaches/<approach-slug>/snippet.txt`

Datei: `.article/config.json`

Datei: `.articles/<article-slug>/content.md`

Datei: `.articles/<article-slug>/snippet.txt`