|
11 | 11 | unterstützen, gibt es mehrere Dinge, auf die man achten kann. |
12 | 12 |
|
13 | 13 | \begin{description} |
14 | | - \item[Einrückung] |
15 | | - Wie euch vermutlich aufgefallen ist, sind an verschiedenen Stellen im |
16 | | - Code einzelne Zeilen ein wenig eingerückt. Dies ist vermutlich das |
17 | | - wichtigste Werkzeug, welches zur Verfügung steht, um die Lesbarkeit von |
18 | | - Code zu unterstützen (auch, wenn es nicht nötig ist, um formal korrekte |
19 | | - Programme zu schreiben). Die einzelnen Einheiten des Kontrollflusss |
20 | | - werden dadurch visuell voneinander abgegrenzt, was es einfacher macht, |
21 | | - den Programmverlauf zu verfolgen. |
| 14 | + \item[Einrückung] |
| 15 | + Wie euch vermutlich aufgefallen ist, sind an verschiedenen Stellen im |
| 16 | + Code einzelne Zeilen ein wenig eingerückt. Dies ist vermutlich das |
| 17 | + wichtigste Werkzeug, welches zur Verfügung steht, um die Lesbarkeit von |
| 18 | + Code zu unterstützen (auch, wenn es nicht nötig ist, um formal korrekte |
| 19 | + Programme zu schreiben). Die einzelnen Einheiten des Kontrollflusss |
| 20 | + werden dadurch visuell voneinander abgegrenzt, was es einfacher macht, |
| 21 | + den Programmverlauf zu verfolgen. |
22 | 22 |
|
23 | | - Wie genau eingerückt werden sollte, darüber scheiden sich die Geister. |
24 | | - Man kann mit mehreren Leerzeichen oder durch Tabulatoren einrücken. |
25 | | - Empfehlenswert ist auf jeden Fall, mehrere gleichförmige „Ebenen“ zu |
26 | | - haben (z.B. 4, 8, 12, \dots\ Leerzeichen zu Beginn der Zeile). Tabulatoren |
27 | | - haben den Vorteil, dass sie, in der Theorie, über Programme hinweg “standartisiert” sind, |
28 | | - weswegen man denselben Code in mehreren Editoren öffnen und |
29 | | - überall problemlos mit Tabulatoren arbeiten kann. Eine |
30 | | - Faustregel für gut lesbare Einrückung ist, immer wenn man eine |
31 | | - geschweifte Klammer öffnet, eine Ebene tiefer einzurücken und immer, |
32 | | - wenn man eine geschweifte Klammer schließt, wieder eine Ebene zurück zu |
33 | | - nehmen. |
34 | | - \item[Klammern] |
35 | | - Aus der Schule kennt ihr das Prinzip „Punkt- vor Strichrechnung“. Dies |
36 | | - ist eine Regel, die so genannte \emph{Präzedenz} ausdrückt, also die |
37 | | - Reihenfolge, in der Operatoren ausgewertet werden. Punkt vor Strich ist |
38 | | - allerdings nicht aussreichend, um vollständig zu beschreiben, wie sich |
39 | | - Operatoren in Gruppen verhalten. Schaut euch z.B. den Ausdruck |
40 | | - \texttt{3 * 2 / 3} an. Da der Computer Ganzzahldivision benutzt, kommen |
41 | | - hier unterschiedliche Ergebniss raus, je nachdem, ob zunächst das |
42 | | - \texttt{*} oder das \texttt{/} ausgewertet wird. Im ersten Fall |
43 | | - erhalten wir \texttt{6 / 3 == 2}, wie wir erwarten würden. Im zweiten |
44 | | - Fall wird aber abgerundet, sodass wir \texttt{3 * 0 == 0} erhalten. |
| 23 | + Wie genau eingerückt werden sollte, darüber scheiden sich die Geister. |
| 24 | + Man kann mit mehreren Leerzeichen oder durch Tabulatoren einrücken. |
| 25 | + Empfehlenswert ist auf jeden Fall, mehrere gleichförmige „Ebenen“ zu |
| 26 | + haben (z.B. 4, 8, 12, \dots\ Leerzeichen zu Beginn der Zeile). Tabulatoren |
| 27 | + haben den Vorteil, dass sie, in der Theorie, über Programme hinweg “standartisiert” sind, |
| 28 | + weswegen man denselben Code in mehreren Editoren öffnen und |
| 29 | + überall problemlos mit Tabulatoren arbeiten kann. Eine |
| 30 | + Faustregel für gut lesbare Einrückung ist, immer wenn man eine |
| 31 | + geschweifte Klammer öffnet, eine Ebene tiefer einzurücken und immer, |
| 32 | + wenn man eine geschweifte Klammer schließt, wieder eine Ebene zurück zu |
| 33 | + nehmen. |
| 34 | + \item[Klammern] |
| 35 | + Aus der Schule kennt ihr das Prinzip „Punkt- vor Strichrechnung“. Dies |
| 36 | + ist eine Regel, die so genannte \emph{Präzedenz} ausdrückt, also die |
| 37 | + Reihenfolge, in der Operatoren ausgewertet werden. Punkt vor Strich ist |
| 38 | + allerdings nicht aussreichend, um vollständig zu beschreiben, wie sich |
| 39 | + Operatoren in Gruppen verhalten. Schaut euch z.B. den Ausdruck |
| 40 | + \texttt{3 * 2 / 3} an. Da der Computer Ganzzahldivision benutzt, kommen |
| 41 | + hier unterschiedliche Ergebniss raus, je nachdem, ob zunächst das |
| 42 | + \texttt{*} oder das \texttt{/} ausgewertet wird. Im ersten Fall |
| 43 | + erhalten wir \texttt{6 / 3 == 2}, wie wir erwarten würden. Im zweiten |
| 44 | + Fall wird aber abgerundet, sodass wir \texttt{3 * 0 == 0} erhalten. |
45 | 45 |
|
46 | | - Um solche und ähnliche Uneindeutigkeiten zu vermeiden, bietet es sich |
47 | | - an, Klammerung zu verwenden. Selbst wenn wir im obigen Fall |
48 | | - \emph{wissen} in welcher Reihenfolge die Operatoren ausgewertet werden, |
49 | | - jemand der unseren Code liest, weiß das vielleicht nicht. Einfach von |
50 | | - vornherein die gewollte Reihenfolge der Auswertung zu klammern, |
51 | | - verhindert Verwirrung bei uns über das Verhalten des Computers, als |
52 | | - auch bei Menschen, die später wissen wollen, was wir meinten. |
| 46 | + Um solche und ähnliche Uneindeutigkeiten zu vermeiden, bietet es sich |
| 47 | + an, Klammerung zu verwenden. Selbst wenn wir im obigen Fall |
| 48 | + \emph{wissen} in welcher Reihenfolge die Operatoren ausgewertet werden, |
| 49 | + jemand der unseren Code liest, weiß das vielleicht nicht. Einfach von |
| 50 | + vornherein die gewollte Reihenfolge der Auswertung zu klammern, |
| 51 | + verhindert Verwirrung bei uns über das Verhalten des Computers, als |
| 52 | + auch bei Menschen, die später wissen wollen, was wir meinten. |
53 | 53 |
|
54 | | - Ihr könnt übrigens nicht nur einzeilige Kommentare erstellen, die mit \cppinline{//} beginnen, sondern auch mehrzeilige, und zwar so: \cppinline{/* Dies ist ein ganz langer mehrzeiliger Kommentar. */} . Alles zwischen den Slashes und Sternchen ist dann ein Kommentar und wird vom Computer ignoriert. Dies könnt ihr als kleinen Trick verwenden, um euren Code zu debuggen, ohne ständig alles neu zu schreiben. Ihr könnt stattdessen einfach den nicht benötigten Code auskommentieren und wenn ihr ihn wieder verwenden wollt, die Kommentarzeichen am Anfang und Ende wieder entfernen. |
55 | | - \item[Kommentare] |
56 | | - Wir haben schon in mehreren Quellcodedateien Kommentare verwendet, um |
57 | | - einzelne Dinge zu erklären. Insgesamt bietet es sich an, dies selbst |
58 | | - ebenfalls zu tun, um den Programmfluss der Leserin von Quellcode klar zu |
59 | | - machen. Das heißt nicht, dass man jede Anweisung noch einmal mit einem |
60 | | - Kommantar versehen sollte, der sie ausführlich erklärt, aber an |
61 | | - wichtigen Punkten können einem kurze Kommentare das Leben enorm |
62 | | - vereinfachen. Und ihr dürft nicht vergessen, dass ihr euch vielleicht |
63 | | - selbst in ein oder zwei Jahren noch einmal euren eigenen Quellcode |
64 | | - anschauen müsst und ihr werdet wirklich überrascht sein, wie wenig ihr |
65 | | - von dem Zeug, welches ihr selbst geschrieben habt, verstehen werdet. |
66 | | - \item [Benennungen] |
67 | | - Wenn ihr eure Variablen -- und später auch eure Funktionen und Klassen -- präzise benennt, dann vereinfacht ihr das Lesen eures Codes extrem. Durch Bezeichnungen, die für sich sprechen, könnt ihr euch außerdem Kommentare etwas ersparen, weil die Variablennamen dann schon viel erklären. Es ist zum Beispiel ungeschickt, seine Variablen wie in der Mathematik üblich einfach nur mit einzelnen Buchstaben zu benennen, statt \cppinline{int a = 42;} sollte man lieber \cppinline{int alter = 42;} verwenden, da die Leserin direkt weiß, dass in dieser Variablen das Alter gespeichert wird. Zu dieser coding style Richtlinie gibt es jedoch auch eine Ausnahme: Bei Zählervariablen, die einfach nur die Anzahl der Schleifeniterationen hochzählen, verwendet man meist einzelne Buchstaben, wie \cppinline{i} oder \cppinline{n}. Das ist schön kurz und praktisch, jedoch muss man etwas aufpassen, denn man kann schnell mit diesen Indices durcheinander kommen -- genau so wie in der Mathematik. |
68 | | - \item[Leerzeichen und -zeilen] |
69 | | - Weniger wichtig als die ersten vier Punkte können trotzdem gezielte |
70 | | - Leerzeichen (z.B. zwischen Operatoren und Operanden in arithmetischen |
71 | | - Ausdrücken) die Lesbarkeit enorm erhöhen. Gerade in arithmetischen |
72 | | - Ausdrücken ist es eine gute Angewohnheit. |
73 | | - Ebenso sind Leerzeilen zwischen logischen Abschnitten sehr hilfreich. Zu Beginn eines Abschnittes kann man dann noch einen kurzen Kommentar hinzufügen, was in dem Abschnitt passiert und schon fällt das Lesen des Codes deutlich leichter. |
| 54 | + Ihr könnt übrigens nicht nur einzeilige Kommentare erstellen, die mit \cppinline{//} beginnen, sondern auch mehrzeilige, und zwar so: \cppinline{/* Dies ist ein ganz langer mehrzeiliger Kommentar. */} . Alles zwischen den Slashes und Sternchen ist dann ein Kommentar und wird vom Computer ignoriert. Dies könnt ihr als kleinen Trick verwenden, um euren Code zu debuggen, ohne ständig alles neu zu schreiben. Ihr könnt stattdessen einfach den nicht benötigten Code auskommentieren und wenn ihr ihn wieder verwenden wollt, die Kommentarzeichen am Anfang und Ende wieder entfernen. |
| 55 | + \item[Kommentare] |
| 56 | + Wir haben schon in mehreren Quellcodedateien Kommentare verwendet, um |
| 57 | + einzelne Dinge zu erklären. Insgesamt bietet es sich an, dies selbst |
| 58 | + ebenfalls zu tun, um den Programmfluss der Leserin von Quellcode klar zu |
| 59 | + machen. Das heißt nicht, dass man jede Anweisung noch einmal mit einem |
| 60 | + Kommantar versehen sollte, der sie ausführlich erklärt, aber an |
| 61 | + wichtigen Punkten können einem kurze Kommentare das Leben enorm |
| 62 | + vereinfachen. Und ihr dürft nicht vergessen, dass ihr euch vielleicht |
| 63 | + selbst in ein oder zwei Jahren noch einmal euren eigenen Quellcode |
| 64 | + anschauen müsst und ihr werdet wirklich überrascht sein, wie wenig ihr |
| 65 | + von dem Zeug, welches ihr selbst geschrieben habt, verstehen werdet. |
| 66 | + \item [Benennungen] |
| 67 | + Wenn ihr eure Variablen -- und später auch eure Funktionen und Klassen -- präzise benennt, dann vereinfacht ihr das Lesen eures Codes extrem. Durch Bezeichnungen, die für sich sprechen, könnt ihr euch außerdem Kommentare etwas ersparen, weil die Variablennamen dann schon viel erklären. Es ist zum Beispiel ungeschickt, seine Variablen wie in der Mathematik üblich einfach nur mit einzelnen Buchstaben zu benennen, statt \cppinline{int a = 42;} sollte man lieber \cppinline{int alter = 42;} verwenden, da die Leserin direkt weiß, dass in dieser Variablen das Alter gespeichert wird. Zu dieser coding style Richtlinie gibt es jedoch auch eine Ausnahme: Bei Zählervariablen, die einfach nur die Anzahl der Schleifeniterationen hochzählen, verwendet man meist einzelne Buchstaben, wie \cppinline{i} oder \cppinline{n}. Das ist schön kurz und praktisch, jedoch muss man etwas aufpassen, denn man kann schnell mit diesen Indices durcheinander kommen -- genau so wie in der Mathematik. |
| 68 | + \item[Leerzeichen und -zeilen] |
| 69 | + Weniger wichtig als die ersten vier Punkte können trotzdem gezielte |
| 70 | + Leerzeichen (z.B. zwischen Operatoren und Operanden in arithmetischen |
| 71 | + Ausdrücken) die Lesbarkeit enorm erhöhen. Gerade in arithmetischen |
| 72 | + Ausdrücken ist es eine gute Angewohnheit. |
| 73 | + Ebenso sind Leerzeilen zwischen logischen Abschnitten sehr hilfreich. Zu Beginn eines Abschnittes kann man dann noch einen kurzen Kommentar hinzufügen, was in dem Abschnitt passiert und schon fällt das Lesen des Codes deutlich leichter. |
74 | 74 | \end{description} |
75 | 75 |
|
76 | 76 | Es gibt sicher noch viele Regeln, über die ihr im Laufe eures Lebens stolpern |
|
82 | 82 | aufzuspüren. Auch wenn es coding style Richtlinien für verschiedene Programmiersprachen gibt, die größtenteils relativ ähnlich sind, gewöhnt man sich meist einen eigenen Stil mit der Zeit an. Es ist allerdings wichtig, früh auf guten Stil zu achten, denn wenn man erst einmal damit anfängt, unübersichtlichen Code zu schreiben, gewöhnt man sich diese Unart an und das will schließlich niemand. |
83 | 83 |
|
84 | 84 | \begin{praxis} |
85 | | - \begin{enumerate} |
86 | | - \item Eine weit verbreitete einfache Aufgabe, die in Bewerbungsgesprächen |
87 | | - auf Stellen als Programmiererin häufig gestellt wird, ist |
88 | | - \emph{FizzBuzz}. In \texttt{fizzbuzz.cpp} ist eine möglich Lösung für |
89 | | - diese Aufgabe gegeben. Könnt ihr (nur mittels des Quellcodes) sagen, |
90 | | - was das Programm tut? |
91 | | - \item Nutzt die oben gegebenen Faustregeln, um den Quellcode lesbarer zu |
92 | | - machen. Ihr müsst nicht alles bis aufs Wort befolgen, macht einfach so |
93 | | - lange weiter, bis ihr findet, man kann hinreichend schnell verstehen, |
94 | | - was hier passieren soll. |
95 | | - \end{enumerate} |
| 85 | + \begin{enumerate} |
| 86 | + \item Eine weit verbreitete einfache Aufgabe, die in Bewerbungsgesprächen |
| 87 | + auf Stellen als Programmiererin häufig gestellt wird, ist |
| 88 | + \emph{FizzBuzz}. In \texttt{fizzbuzz.cpp} ist eine möglich Lösung für |
| 89 | + diese Aufgabe gegeben. Könnt ihr (nur mittels des Quellcodes) sagen, |
| 90 | + was das Programm tut? |
| 91 | + \item Nutzt die oben gegebenen Faustregeln, um den Quellcode lesbarer zu |
| 92 | + machen. Ihr müsst nicht alles bis aufs Wort befolgen, macht einfach so |
| 93 | + lange weiter, bis ihr findet, man kann hinreichend schnell verstehen, |
| 94 | + was hier passieren soll. |
| 95 | + \end{enumerate} |
96 | 96 |
|
97 | | - \inputcpp{fizzbuzz.cpp} |
| 97 | + \inputcpp{fizzbuzz.cpp} |
98 | 98 | \end{praxis} |
99 | 99 |
|
100 | 100 | \begin{spiel} |
101 | | - \begin{enumerate} |
102 | | - \item Entfernt in eurem veränderten Quellcode eine geschweifte Klammer |
103 | | - eurer Wahl. Lasst eure Sitznachbarin über den Quellcode schauen und die |
104 | | - fehlende Klammer finden. |
105 | | - \end{enumerate} |
| 101 | + \begin{enumerate} |
| 102 | + \item Entfernt in eurem veränderten Quellcode eine geschweifte Klammer |
| 103 | + eurer Wahl. Lasst eure Sitznachbarin über den Quellcode schauen und die |
| 104 | + fehlende Klammer finden. |
| 105 | + \end{enumerate} |
106 | 106 | \end{spiel} |
107 | 107 |
|
108 | 108 | \textbf{Quiz 12}\\ |
109 | 109 | \textit{Was gehört zu gutem Coding style?} |
110 | 110 | \begin{enumerate}[label=\alph*)] |
111 | | - \item Sinnvolle Kommentare |
112 | | - \item Möglichst keine Leerzeilen lassen |
113 | | - \item Variablennamen möglichst kurz wählen |
114 | | - \item Einrückungen vornehmen |
| 111 | + \item Sinnvolle Kommentare |
| 112 | + \item Möglichst keine Leerzeilen lassen |
| 113 | + \item Variablennamen möglichst kurz wählen |
| 114 | + \item Einrückungen vornehmen |
115 | 115 | \end{enumerate} |
0 commit comments