From 6b87dc02c46b99a3e15f1b1e5b53e62767225efa Mon Sep 17 00:00:00 2001
From: Herbert Reiter <46045854+damoasda@users.noreply.github.com>
Date: Sat, 29 Jun 2024 08:54:51 +0200
Subject: [PATCH] Begriff Betreuer durch Entwickler ersetzen

---
 src/ch03-01-variables-and-mutability.md            |  9 ++++-----
 ...2-03-improving-error-handling-and-modularity.md | 14 +++++++-------
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/src/ch03-01-variables-and-mutability.md b/src/ch03-01-variables-and-mutability.md
index b26f23d..38fc83b 100644
--- a/src/ch03-01-variables-and-mutability.md
+++ b/src/ch03-01-variables-and-mutability.md
@@ -158,11 +158,10 @@ nützliche Wahl für Werte in deiner Anwendungsdomäne, über die mehrere Teile
 Programms Bescheid wissen müssen, z.B. die maximale Punktzahl, die jeder
 Spieler eines Spiels erhalten darf, oder die Lichtgeschwindigkeit.
 
-Das Benennen von hartkodierten Werten, die im gesamten Programm als Konstanten
-verwendet werden, ist nützlich, um die Bedeutung dieses Wertes zukünftigen
-Code-Betreuern zu vermitteln. Es ist auch hilfreich, nur eine Stelle in deinem
-Code zu haben, die du ändern musst, wenn der hartkodierte Wert in Zukunft
-aktualisiert werden müsste.
+Hartkodierte Werte, die im gesamten Programm als Konstanten verwendet werden,
+sollten benannt werden, damit zukünftigen Entwicklern die Bedeutung dieses
+Wertes vermittelt wird. Zudem ist es hilfreich, nur eine Codestelle ändern zu
+müssen, sollte der hartkodierte Wert irgendwann zu ändern sein.
 
 ### Verschatten (shadowing)
 
diff --git a/src/ch12-03-improving-error-handling-and-modularity.md b/src/ch12-03-improving-error-handling-and-modularity.md
index 4a156f6..72dbc9f 100644
--- a/src/ch12-03-improving-error-handling-and-modularity.md
+++ b/src/ch12-03-improving-error-handling-and-modularity.md
@@ -33,7 +33,7 @@ Viertens verwenden wir `expect` erneut, um einen Fehler zu behandeln, und wenn
 der Benutzer unser Programm ausführt, ohne genügend Argumente anzugeben, erhält
 er einen `Index out of bounds`-Fehler von Rust, der das Problem nicht eindeutig
 erklärt. Am besten wäre es, wenn sich der gesamte Fehlerbehandlungscode an
-einer Stelle befände, sodass zukünftige Betreuer nur eine Stelle im Code
+einer Stelle befände, sodass zukünftige Entwickler nur eine Stelle im Code
 konsultieren bräuchten, falls sich die Fehlerbehandlungslogik ändern sollte.
 Wenn sich der gesamte Fehlerbehandlungscode an einer Stelle befindet, wird auch
 sichergestellt, dass wir Meldungen ausgeben, die für unsere Endbenutzer
@@ -141,12 +141,12 @@ dass wir vielleicht noch nicht die richtige Abstraktion haben.
 Ein weiterer Indikator, der zeigt, dass es Raum für Verbesserungen gibt, ist
 der `config`-Teil von `parse_config`, der impliziert, dass die beiden von uns
 zurückgegebenen Werte miteinander in Beziehung stehen und beide Teil eines
-Konfigurationswertes sind. Diese Bedeutung vermitteln wir derzeit in der
-Struktur der Daten nur durch die Gruppierung der beiden Werte in einem Tupel;
-wir werden stattdessen die beiden Werte in eine Struktur setzen und jedem der
-Strukturfelder einen aussagekräftigen Namen geben. Auf diese Weise wird es
-künftigen Betreuern dieses Codes leichter fallen, zu verstehen, wie die
-verschiedenen Werte miteinander in Beziehung stehen und was ihr Zweck ist.
+Konfigurationswertes sind. Diese Bedeutung vermitteln wir derzeit nur durch die
+Gruppierung der beiden Werte in einem Tupel. Geben wir daher die beiden Werte
+in einer Struktur an und geben jedem der Strukturfelder einen aussagekräftigen
+Namen. Auf diese Weise wird es künftigen Entwicklern dieses Codes leichter
+fallen, zu verstehen, wie die verschiedenen Werte miteinander in Beziehung
+stehen und was ihr Zweck ist.
                                                    
 Codeblock 12-6 zeigt die Verbesserungen der Funktion `parse_config`.