15  Programmieren

15.1 Schöner Programmieren

• Schreiben Sie Ihren Code in kleine, in sich abgeschlossene Abschnitte.
• Gliedern Sie Ihren Code in Funktionen.
• Schreiben Sie nicht “hardcoded”, sondern verwenden Sie allgemeinere, wiederverwendbare, flexible Strukturen.
• Finden Sie prägnante Namen für Ihre Objekte.
• Kommentieren Sie Ihren Code.
• Nutzen Sie (nach Möglichkeit) Quarto, um Ihren Code und Ihre Ergebnisse zu dokumentieren.
• Nutzen Sie Git und GitHub, um Ihren Code zu versionieren und zu teilen.
• Nutzen Sie möglichst einfach verständlichen Code; schreiben Sie in erster Linie für Menschen, und erst in zweiter Linie für Maschinen.
• Nutzen Sie bewährte (R-)Pakete, um Ihre Arbeit zu erleichtern.
• Nutzen Sie die Tidyverse-Pakete, soweit möglich, um Ihren Code zu schreiben.
• Verwenden Sie den Tidyverse-Styleguide.

15.1.1 Code vereinfachen

Datenbeispiel:

d <-
  tibble(
    x = c(1, 2, 3, NA, 5),
    y = c(NA, 2, 3, 4, 5),
    z = 1
  )

d

Komplizierter Code:

d_no_const_cols <- 
  d[, sapply(d, function(col) length(unique(col[!is.na(col)])) > 1)]
d_no_const_cols

Einfacher Code:

d_no_const_cols <- 
  d |> select(where(~ n_distinct(.) > 1))
d_no_const_cols

Ähnlicher, aber nicht unbedingt einfacherer Cogixode:

nicht_alle_gleich <- function(spalte){
  n_distinct(spalte) > 1
}

d |> select(where(nicht_alle_gleich))

Sehr einfacher Code:

d_no_const_cols <- 
  d |> remove_constant()  # aus janitor
d_no_const_cols

Hilfe zur Funktion remove_constant erhält man mit ?remove_constant (das zugehörige Paket, janitor, muss dafür geladen sein).

15.2 Pipelines mit Targets

15.2.1 Einführung

Eine Analyse mit vielen Schritten kann leicht unübersichtlich werden. Ein anderes Problem ist, dass man viele Objekte erzeugt, als Ergebnisse der Zwischenschritte. Ändert man einen Zwischenschritt, so ändert sich der Input für alle darauf folgende Analyseschritte. Man muss also nachfolgenden Objekte neu berechnen. Gefährlich wäre, würde man vergessen, diese Objekte neu zu berechnen: Man würde mit einem “veralteten” also falschen Objekt weiterarbeiten, was zwangsläufig zu falschen Ergebnissen führten würde.

Wäre es nicht schön, wenn es ein Tool gäbe, das für Sie den Überblick behält und dafür sorgt, dass die veralteten Objekte (und nur die) bei Bedarf neu berechnet werden?

Solche Tools gibt es. Wir schauen uns dazu das Tool targets an.

Hier ist ein erstes Beispiel, und hier ist eine weitere Einführung in Targets.

Diese Präsentation führt in Targets ein mit einer Data-Science-Anwendung.

15.2.2 Richtlinien

Wenn Sie eine Analyse mit Targets durchführen, sollten Sie folgende Richtlinien beachten:

• Schreiben Sie Ihre Targets-Pipeline in einer separaten Datei.
• In einer Targets-Pipeline-Datei sollte nur die Pipeline stehen (inkl. Vorbereitung wie Pakete bereitstellen etc.).
• Eine Targets-Pipeline-Datei ist ein reines R-Skript.
• Wenn Sie Funktionen schreiben, die Sie in der Pipeline verwenden, schreiben Sie diese in einer separaten Skript-Datei (oder pro Funktion eine eigene Skript-Datei).
• Reichen Sie alle Dateien, also auch die Funktionen-Skripte, ein.

15.3 Tipps

• Wiederholen Sie die Grundlagen des Datenjudos.
• Programmieraufgaben sind angewandt; theoretische Konzepte stehen nicht im Vordergrund. Stattdessen geht es darum, praktische Probleme zu lösen. In solchen Situationen geht Probieren (oft) über Studieren.
• Häufig ist es nützlich, nicht sofort loszuschreiben, sondern sich in Ruhe einen Plan für die Lösung zu machen. Zwei Minuten Nachdenken ersetzt oft zwanzig Minuten Programmieren.
• Wenn Sie nicht weiterkommen, suchen Sie Hilfe. Das kann ein Kommilitone, ein Buch, ein Online-Tutorial oder ein Chatbot sein.
• Ein bekanntest und gutes Buch für guten Programmierstil haben Thomas und Hunt (2020) geschrieben.

15.4 Literatur

Thomas, David, und Andrew Hunt. 2020. The Pragmatic Programmer: Your Journey to Mastery. Second edition, 20th anniversary edtion. Boston: Addison-Wesley.