Coding Conventions

Die Entwicklung von Software zeichnet sich in der heutigen Welt oft dadurch aus, dass sie unter Mitwirkung unterschiedlichster Entwickler bewerkstelligt wird. Im Rahmen einer solchen Entwicklung kommt es darauf an, bestimmte Standards und Best Practices einzuhalten.

Neben dem passenden Workflow kommen hier Coding Conventions zum Tragen und bilden einen wichtigen Baustein um Quelltext effizienter, lesbarer und zuverlässiger zu gestalten.

Was sind Coding Convention?

Eine Coding Convention definiert sich über bestimmte Stilregeln und Best Practices, bezogen auf eine Programmiersprache. Innerhalb der Konvention werden viele Aspekte der Programmiersprache und ihrer sprachlichen Elemente behandelt. Dies fängt bei Regeln zur Formatierung an, führt sich fort mit der Benamung von Variablen und anderen Strukturen und erstreckt sich auch auf andere Bereiche, wie Reihenfolgen und Zeilenlängen.

Warum werden sie benötigt?

Nun kann sich natürlich die Frage gestellt werden, warum eigentlich Coding Conventions benötigt werden?

Neben offensichtlichen Gründen, dass sie vielleicht eine Anforderung des Kunden sind, gibt es auch andere Gründe für diese Konventionen. So werden die meisten Projekte nicht von einer einzelnen Person betreut und für die Entwickler eines Produktes ist es einfacher, wenn der Quelltext nach identischen Standards entwickelt wurde. Dies ermöglicht eine schnellere Einarbeitung und hilft auch bei anderen Dingen, wie der Verminderung von Merge-Konflikten bei der Arbeit mit Versionskontrollsystemen.

Damit tragen diese Konventionen dazu bei, die Zusammenarbeit zwischen Entwicklern zu erleichtern, indem sie eine einheitliche und konsistente Basis schaffen.

Eine Welt ohne Coding Conventions

Natürlich können Programme auch ohne Coding Conventions geschrieben werden. Dies kann zu interessanten Programmen führen:

#include 

...

yeet Yeet Yeeet yeeeT 
Yeeeet
yEet yEEt yeEt yyeet yeett yeetT
yeeT yet yeetT
yeeeeT

Bei diesem Programm stellen sich bei der Betrachtung mehrere Fragen. In welcher Sprache ist es geschrieben? Ist es überhaupt lauffähig? Und was ist der eigentliche Zweck des Quelltextes?

In diesem Beispiel wurde das C-Programm so gestaltet, dass es möglichst unlesbar ist, indem mit entsprechenden Definitionen gearbeitet wurde, welche anschließend im Quelltext genutzt werden.

#define yeet int
#define Yeet main
#define yEet std
#define yeEt cout
#define yeeT return
#define Yeeet (
#define yeeeT )
#define Yeeeet {
#define yeeeeT }
#define yyeet <<
#define yet 0
#define yeett "Yeet!"
#define yeetT ;
#define yEEt ::

Es zeigt auf, dass ohne einheitliche Coding Conventions im besten Fall Chaos droht. Auf die Spitze treibt das auch der International Obfuscated C Code Contest, bei welchem es darum geht, Quelltext möglichst so zu verschleiern, dass nur schwer zu erraten ist, welche Funktion dieser am Ende in sich trägt.

Eine Implementation des zcat-Kommandos

In diesem Beispiel wird der Befehl zcat zur Darstellung mittels gz-komprimierter Daten implementiert. Auch ohne solche Extrembeispiele würde in einer Welt ohne Coding Conventions eine Menge an inkonsistentem Code entstehen:

int counterServer = 1               ;
int counterClient = 2               ;
int counterDevice = 3               ;
int test1 = 4                       ;

Natürlich kann ein Quelltext so formatiert werden, aber in den meisten Fällen erschwert dies die Lesbarkeit des Quelltextes enorm. Auch die Nutzung von Whitespaces und falscher Einrückung kann zu Problemen führen:

if        (system==true) {
    doSomething()        ;
doFoobar                       ();
}

Auch Richtlinien über Komplexität sind ein wichtiger Bestandteil, solcher Konventionen. Gegeben sei folgendes Programm:

#include

main(){
  int x=0,y[14],*z=&y;*(z++)=0x48;*(z++)=y[x++]+0x1D;
  *(z++)=y[x++]+0x07;*(z++)=y[x++]+0x00;*(z++)=y[x++]+0x03;
  *(z++)=y[x++]-0x43;*(z++)=y[x++]-0x0C;*(z++)=y[x++]+0x57;
  *(z++)=y[x++]-0x08;*(z++)=y[x++]+0x03;*(z++)=y[x++]-0x06;
  *(z++)=y[x++]-0x08;*(z++)=y[x++]-0x43;*(z++)=y[x]-0x21;
  x=*(--z);while(y[x]!=NULL)putchar(y[x++]);
}

Bei diesem handelt es sich um ein einfaches Hello World-Programm, aber das Verständnis wird durch die Umsetzung, genauer gesagt dessen unnötige Komplexität, sehr erschwert.

Auch wenn sich auf Einrückungen geeinigt wird, ist dies nicht immer sinnvoll:

function f() {
  doThings();
  doMoreThings();
             }

Bei diesem Beispiel wird eine Einrückung genutzt, welche ungebräuchlich ist und bei den meisten Entwicklern wahrscheinlich auf Ablehnung stoßen wird und nicht dazu führt, dass der Quelltext übersichtlicher wird.

Die Benamung von Elementen ist ein wichtiger Teil von Coding Conventions:

void doSomeTHING() {
  int test1 = 1;
  int TEST2 = 2;
  int teST3 = 3;
}

void DoSomething() {
  int tEST4 = 4;
}

Wird bei dieser nicht auf Konsistenz geachtet, trägt dies nicht zum besseren Verständnis bei. Auch Kommentare, bzw. das Schreiben derselben sind eine Aufgabe, bei der sorgfältig gearbeitet werden sollte:

try {
  ...
} catch(Exception e) {
  // Gotta Catch 'Em All
}

Natürlich ist Humor im echten Leben wichtig, aber in einem Quelltext sollte er nichts zu suchen haben. Stattdessen sollte sich hier auf die Fachlichkeit bezogen werden.

Auch die Nutzung unüblicher Vorgehensweisen bzw. das Verstecken bestimmter Operationen erschwert das Verständnis eines Quelltextes:

int main() {

  String helloWorld = "Hello World!";
  cout << helloWorld << endl;

  String hello = (helloWorld, 5);
  cout << hello << endl;

  system("pause");
  return 0;
}

Ohne weitere Informationen ist es relativ schwer herauszufinden, was in diesem Beispiel passiert. Hier werden die ersten fünf Stellen der Zeichenkette Hello World! zurückgegeben. In diesem Fall geschieht dies über die Überladung des Komma-Operators:

using namespace std;

#define String string

String operator,(String lhs, int rhs) {
  lhs.erase(lhs.begin() + rhs, lhs.end());
  return lhs;
}

Auch eine schlechte Benennung und ein Sprachmischmasch kann das Verständnis des Quelltextes erschweren:

#include 

gibHalloWeltAus()
{
    // use cout for output
    cout << "Hello World!" << endl;

    // Rückgabereturn
    return 0;
}

Ziele von Coding Conventions

Wenn sich diese Beispiele aus der Welt ohne Coding Conventions angeschaut werden, können aus diesen einige Ziele für entsprechende Konventionen abgeleitet werden.

Es geht darum, dass Coding Conventions bewährte Praktiken abbilden und für einen lesbaren und verständlichen Quelltext sorgen. Sie sollen die Zusammenarbeit im Team erleichtern und eine gewisse Einheitlichkeit herstellen.

Daneben sind Coding Conventions und das Konzept von Clean Code miteinander verbunden. Clean Code ist ein Konzept, das sich auf die Softwareproduktion und das Programmierdesign bezieht. Es legt fest, dass Quelltext so geschrieben werden sollte, dass er einfach zu lesen, zu verstehen und zu warten ist. Die Einhaltung von Coding Conventions kann dazu beitragen, diese Kriterien einzuhalten.

Elemente von Coding Conventions

Doch woraus genau bestehen Coding Conventions im Einzelnen? Im ersten Schritt sollte sich bewusst gemacht werden, dass sich solche Konventionen von Sprache zu Sprache unterscheiden. Auch wenn sich im Laufe der Zeit einige Standards herauskristallisiert haben, können diese nicht immer eins zu eins auf die eigenen Anforderungen angewendet werden.

Unterschiedliche Elemente von Coding Conventions

Im Einzelnen setzen sich Coding Conventions aus Elementen zusammen, welche im folgenden genauer besprochen werden sollen.

Benamung

Ein essenzielles Element ist die Benamung innerhalb eines Entwicklungsprojektes. Dies fängt bei Dateinamen und Verzeichnissen an, zieht sich hin zu Bezeichnern, wie den Namen von Variablen, Klassen und vielen anderen Elementen.

Grundsätzlich sollte bei der Benamung von Elementen immer so viel wie nötig und so wenig wie möglich benannt werden.

Dateinamen

Da Coding Conventions sich von Sprache zu Sprache unterscheiden, existieren bereits Unterschiede auf Ebene der Dateinamen. Während Dateien von C-Programmen meist in Kleinschreibung benannt werden:

main.c
tilerenderer.c

sieht dies bei Java-Applikationen anders aus:

Main.java
TileRenderer.java

Neben den Dateinamen bezieht sich dies auch auf die Benamung und Struktur von Verzeichnissen. In C würde dies wie folgt aussehen:

src
  engine
  renderer
  utils

während in Java meist die Struktur des Packages abgebildet wird. Bei dem Package com.example.transformer.html würde die entsprechende Verzeichnisstruktur wie folgt aussehen:

src
  main
    java
      com
        example
          transformer
            html
            markdown
  test

Eine weitere Eigenart von Java ist, dass die Namen der Packages eine Domain-Struktur abbilden und z. B. mit der Domain der Firma beginnen.

Neben den Coding Conventions für die jeweilige Sprache gehen bei der Strukturierung des Projektes auch noch andere Aspekte ein. Wird z. B. mit dem Build-Werkzeug Maven gearbeitet, so gilt dort Konvention vor Konfiguration.

Bei Maven bedeutet dies, dass eine Reihe von Standardregeln existieren, die vom Benutzer des Werkzeuges befolgt werden müssen, um ein Projekt erfolgreich zu erstellen. So muss ein Projekt in einer bestimmten Struktur organisiert sein, damit Maven es erfolgreich verarbeiten kann. Diese Standards erleichtern es, ein Projekt mit Maven zu erstellen, da der Benutzer nicht jeden einzelnen Schritt konfigurieren muss.

Sprechende Namen

Auch bei der Benamung sollten gewissen Standards eingehalten werden:

int a = getSum();

In diesem Fall wird eine Methode mit dem Namen getSum aufgerufen und das Ergebnis in der Variable a gespeichert. Hier sollte mit sprechenden Namen gearbeitet werden. Solche Namen zeichnen sich dadurch aus, dass sie beim Lesen bereits Aufschluss über ihre Fachlichkeit und deren Bedeutung geben:

int sum = getSum();

Damit wird klar, dass sich in der Variable sum eine entsprechende Summe befindet. Theoretisch kann die Benennung natürlich noch weiter spezifiziert werden:

int sumArticles = getSum();

Unter Umständen können Namen hierbei etwas länger werden, aber dafür wird Klarheit gewonnen. Diese Art der Benamung sollte nicht nur für Variablen, sondern generell für Bezeichner, wie Klassennamen gelten.

Allerdings keine Regel ohne Ausnahme, z. B. bei Exceptions unter Java:

try {
  // Try some funky stuff
} catch(Exception e) {
  // Handle exception
}

Dort hat es sich eingebürgert, einer Exception den Namen e bzw. ex zu geben. Sind solche Konventionen vorhanden und weitverbreitet, sollten diese entsprechend eingehalten werden. Auch hier dient das Einhalten dieser Regeln dazu, die Lesbarkeit und Wartbarkeit des Quelltextes zu erhöhen.

Verbotene Bezeichner

Es gibt eine Reihe von Bezeichnungen, welche in der Theorie, je nach verwendeter Sprache, verwendet werden können, es aber nicht sollten.

So ist es in Sprachen wie C# möglich, mit einem vorgestellten At-Zeichen Schlüsselwörter der Sprache als Bezeichner verwenden zu können. Um Verwirrung und darauf aufbauende Probleme zu vermeiden, sollte dies unterlassen werden.

Andere Bezeichner, wie handle, sollten nur in einem eng begrenzten Kontext oder einer entsprechenden Fachlichkeit benutzt werden.

Auch die Nutzung von Variablen mit dem Namen temp oder tmp sollte unterlassen werden, da meist eine entsprechend sinnvollere fachliche Benamung möglich ist.

Schleifen und Benamung

Wie bei Exceptions haben sich auch bei Schleifen bestimmte Konventionen zur Benamung eingebürgert, an welche sich gehalten werden sollte:

for(int i = 0; i < 10; i++) {

    for(int j = 0; j < 10; j++) {

      // Do stuff
    }
}

So wird die Zählervariable bei Schleifen mehrheitlich mit dem Namen i benannt und wenn in der Schleife weitere Schleifen geschachtelt werden, so werden diese fortlaufend mit j, k und so weiter benannt.

Aber auch hier kann in Ausnahmen davon abgewichen werden. Ein Beispiel hierfür wäre z. B. die Verarbeitung eines Bildes:

for(int y = 0; y < image.height; y++) {

    for(int x = 0; x < image.width; x++) {

      // Do image stuff
    }
}

Hier wird sich auf die x- und y-Achse des Bildes bezogen und durch die entsprechende Benamung kann sinnvoll mit diesen in der eigentlichen Logik der Schleife gearbeitet werden.

Kamele, Dromedare und Schlangen

Bezeichner können wie bei obigem Beispiel einfache Namen bestehend aus einem Wort sein, bestehen aber in vielen Fällen aus mehreren Wörtern.

Unterschiedlichste Schreibvarianten bei zusammengesetzten Bezeichnern

Um diese sinnvoll miteinander zu verbinden werden je nach Sprache unterschiedliche Varianten von Binnenmajuskeln benutzt, welche je nach Verwendung treffende Namen wie CamelCase und Ähnliche tragen. Diese Schreibweise sorgt letztlich für eine bessere Lesbarkeit, da sie einzelne Wörter sinnvoll voneinander abgrenzt.

Binde- und Unterstriche

Neben der Schreibweise mittels Binnenmajuskeln existieren auch andere Schreibweisen, was sich im Beispiel wie folgt darstellt:

do_things_fast();
do-things-fast();

So wird in Sprachen wie C und Perl auch auf Unterstriche zurückgegriffen und auch in PHP war dies bis zur Version 4 der Fall. Die Schreibweise mit dem Bindestrich, welche auch als lisp-case bekannt ist, wurde unter anderem in COBOL und Lisp genutzt.

Auch bei Rust wird teilweise auf Unterstriche als auch auf CamelCase gesetzt.

Ausnahmen bei der Benamung

Je nach Sprache wird damit meist eine bestimmte Schreibweise für Bezeichner wie den Namen von Variablen genutzt, allerdings existieren hiervon auch Ausnahmen bzw. Abweichungen, wie bei der Definition von Konstanten:

public static final String SECRET_TOKEN = "X7z4nhty3287";

Diese werden in vielen Fällen komplett großgeschrieben und meist mit Unterstrichen unterteilt. Auch hier gilt wieder, dass solche Konstanten möglichst sprechend benannt werden sollten und auf Abkürzungen und Ähnliches verzichtet werden sollte.

Prä- und Suffixe

In der Vergangenheit wurden an Bezeichner teilweise Prä- und Suffixe mit angetragen. Begründet war dies mit den damaligen Compilern und der fehlenden Unterstützung in der Entwicklungsumgebung. Durch die Nutzung eines Präfixes konnte so z. B. der Typ einer Variable aus dem Namen ermittelt werden.

Die sicherlich bekannteste Notation ist die Ungarische Notation. Hier werden die Bezeichner aus einem Präfix für die Funktion, einem Kürzel für den Datentyp und einem Bezeichner zusammengesetzt.

Ein Beispiel für einen solchen Namen wäre die Variable idValue, welche anzeigt, dass es sich um einen Index vom Typ Double handelt, welcher den Namen Value trägt.

Mittlerweile wird diese Notation in der Praxis nur noch selten genutzt. Auch Linus Torvalds hatte sich dazu geäußert:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged – the compiler knows the types anyway and can check those, and it only confuses the programmer.

Neben der besseren Unterstützung der IDEs gibt es andere Gründe, welche gegen eine Nutzung der ungarischen Notation sprechen. So kann z. B. bestehender Quelltext schlechter migriert werden, wenn sie die Namen nicht ändern dürfen, aber die Typen dies tun. Dies war z. B. der Fall bei der Umstellung der WinAPI auf eine 64-Bit fähige API, bei dem Namen nun nicht mehr auf den korrekten Datentyp hinweisen.

Einrückungen

Neben der Benennung von Bezeichnern ist auch die Einrückung ein unter Umständen recht emotionales Thema.

Dabei geht es hauptsächlich darum, ob Leerzeichen oder Tabulatoren für die Einrückungen genutzt werden. Aus pragmatischer Sicht sollte hier insbesondere die Mischung dieser beiden Varianten verhindert werden.

Für Leerzeichen spricht, dass die Einrückungen bei allen Nutzern identisch aussehen. Im Gegensatz zu Tabulatoren benötigen Leerzeichen, mehr Speicher. Vier Leerzeichen belegen 4 Byte, ein Tabulator nur ein Byte.

Bei Tabulatoren kann der Einzug in der Entwicklungsumgebung individuell konfiguriert werden, was aber gleichzeitig den Nachteil ergibt, dass der Quelltext bei unterschiedlichen Mitarbeitenden anders aussehen kann.

Persönlich würde der Autor an dieser Stelle immer Leerzeichen empfehlen. Damit ist ein Quelltext gewährleistet, welcher bei jedem Entwickler identisch aussieht. Der zusätzliche Speicherbedarf kann hierbei vernachlässigt werden.

Einrückungstiefen

Bei der Frage der Leerzeichen stellt sich auch die Frage, mit wie vielen Leerzeichen soll ein Block eingerückt werden. Hier ergibt sich die Möglichkeit, dies mit zwei Leerzeichen je Block zu machen:

void main() {
  doSomething();
}

Der Standard bei vielen Projekten sind hingegen vier Leerzeichen:

void main() {
    doSomething();
}

Allerdings sind auch acht Leerzeichen gebräuchlich, z. B. beim Linux-Kernel. Wirklich bemerkbar wird dies allerdings erst dann, wenn mehrere Blöcke ineinander verschachtelt werden:

void main() {

    for(int i = 0; i < 10; i++) {

        for(int j = 0; j < 10; j++) {

            doSomething();
        }
    }
}

Je nach Ausgabeformat, z. B. beim Ausdruck oder in Präsentationen ist es sinnvoll auf zwei Leerzeichen zu setzen, aber im Allgemeinen sollten vier Leerzeichen genutzt werden.

Whitespaces und Leerzeilen

Neben der Einrückung sind auch die Whitespaces im Quelltext selbst, sowie Leerzeilen ein Element zur Strukturierung des Quelltextes.

Leerzeilen stellen ein wichtiges Element zur Strukturierung dar. Natürlich kann ein Quelltext ohne Leerzeilen geschrieben werden und leider ist dies in der Praxis oft zu sehen. Sinnvoll ist es aber, den Quelltext etwas weiträumiger zu gestalten:

int getResult(int a, int b) {

    int sum = getSum();
    int ret = 0;

    for(int i = 0; i < 10; i++) {
        ret += sum;
    }

    return ret;
}

Die Trennung einzelner Bestandteile des Quelltextes durch Leerzeilen sollte anhand der funktionalen Blöcke bzw. nach der Fachlichkeit vorgenommen werden.

Neben den Leerzeilen, sind auch Whitespaces ein essenzieller Teil der Formatierung eines Quelltextes. Whitespaces definieren sich allgemein als Leerstellen in Text, Code oder Schrift, die zwischen Zeichen, Wörtern, Zeilen oder Absätzen liegen. In der Programmierung werden Whitespaces auch als Formatierung verwendet, um den Quelltext leserlicher zu machen und den Code übersichtlicher zu strukturieren.

Whitespaces verbessern die Sichtbarkeit und das Verständnis der Syntax:

int sum=a+b;

for(int i=0;i<10;i++) {
    doSomething();
}

Bei diesem Beispiel wäre es wesentlich sinnvoller, Leerzeichen zum Strukturieren zu nutzen und dem Quelltext eine gewissen Luftigkeit zu geben:

int sum = a + b;

for(int i = 0; i < 10; i++) {
    doSomething();
}

Dies erhöht die Lesbarkeit und sorgt letztlich für ein besseres Verständnis. Natürlich kann auch an dieser Stelle übertrieben werden:

for ( int i = 0; i < 10; i++ ) {
    doSomething ( ) ;
}

So werden hier auch Leerzeichen rund um die Klammern gesetzt, was im Normalfall nicht sonderlich hilfreich ist und deshalb unterlassen werden sollte.

Blockklammern

In vielen Programmiersprachen wird mit Blöcken gearbeitet. Ein Block definiert sich als eine Gruppe von Anweisungen, die als eine Einheit behandelt werden. So wird über den Block z. B. der Gültigkeitsbereich von Variablen definiert. Ein Block beginnt normalerweise mit einer öffnenden geschweiften Klammer und endet mit einer schließenden Klammer gleichen Typs.

Beispielsweise kann ein Block zu einer if-Anweisung gehören, in der eine Reihe von Anweisungen ausgeführt werden, wenn die Bedingung wahr ist. Hier kann natürlich die Frage nach der Notwendigkeit gestellt werden, wie in diesem Stück Java-Code:

if(something == true)
    doFooBar();

So würde dieses Beispiel ohne Probleme kompilieren und wenn die Bedingung zutrifft, die Methode doFooBar aufgerufen werden. Problematisch wird dieses Konstrukt allerdings dann, wenn der Quelltext an dieser Stelle erweitert wird:

if(something == true)
    doAnotherThing();
    doFooBar();

Nun würde nur noch die Methode doAnotherThing ausgeführt werden. Die andere Methode hingegen nicht mehr. Aus dem Quelltext ist dies allerdings nicht ohne Weiteres ersichtlich. Aus diesem Grund sollte immer mit Blockklammern gearbeitet werden, auch wenn nur eine einzelne Anweisung folgt:

if(something == true) {
    doFooBar();
}

Dadurch werden Fehler vermieden und die Intention des Quelltextes wird sofort ersichtlich.

Position der Klammern

Für die Positionierung der geschweiften Blockklammern gibt es in der Praxis zwei verbreitete Varianten, diese zu setzen. Bei der ersten Variante sind sie beide auf der gleichen Ebene zu finden:

boolean get()
{
    int a = 7;
    int b = 42;

    int result = doFooBar(7, 42);

    if(result == 23) 
    {
        return false;
    }

    return true;
}

Der Vorteil an dieser Variante ist, dass sofort zu sehen ist, wo ein Block beginnt und wo sich die entsprechende schließende Klammer des jeweiligen Blockes befindet. Als Nachteil wird bei dieser Variante oft aufgeführt, dass damit etwas Platz verschwendet wird.

Bei der anderen gebräuchlichen Variante wird die öffnende Klammer eines Blockes direkt hinter die Anweisung gesetzt, welche zum öffnenden Block gehört:

boolean get() {

    int a = 7;
    int b = 42;

    int result = doFooBar(7, 42);

    if(result == 23) {
        return false;
    }

    return true;
}

Dies erschwert zwar die Zuordnung zwischen dem Beginn des Blockes und dem Ende, allerdings zeigen die meisten modernen IDEs diese Zuordnung prominent an.

In der Theorie wird bei dieser Variante eine Zeile eingespart, allerdings ist es sinnvoll nach der öffnenden Blockklammer eine Leerzeile zu setzen, um die Übersichtlichkeit zu erhöhen.

Häufig wird noch ein Unterschied zwischen einzeiligen und mehrzeiligen Blöcken gemacht:

if(something == true) {
    doFooBar();
}

Dort wird die Leerzeile weggelassen, während sie bei mehrzeiligen Blöcken immer eingefügt wird:

if(something == true) {

    doFooBar();
    doSomething();

    for(int i = 0; i < 10; i++) {
        doThings();
    }    
}

Blöcke per Einrückung

Neben Sprachen mit solchen Blockklammern existieren auch Sprachen wie Python, welche andere Wege zur Strukturierung von Blöcken nutzen:

import sys
import random

running = True

while running:

    randomNumber = random.randint(0,8)

    if randomNumber == 0:
        break;
        
    else:
        print(randomNumber)

Hier wird die Zuordnung zu einem Block über die entsprechende Einrückung vorgenommen. Damit entfällt die Frage nach der Position der Blockklammern.

Reihenfolgen

In vielen Programmiersprachen gibt es Schlüsselwörter, wie Modifikatoren für die Sichtbarkeit. Für diese empfiehlt es sich auch eine entsprechende Reihenfolge zu definieren und diese einzuhalten.

Am Beispiel von Java wäre dies die Sichtbarkeit, dann eine eventuelle static-Definition gefolgt von einer final-Definition und am Ende der eigentlichen Definition:

public int a = 7;
public final int b = 24;
public static final int c = 42;

Auch bei Systemen zur statischen Codeanalyse, wie Sonarlint, sind solche Regeln hinterlegt.

Reihenfolge im Quelltext

Neben den Namen der Bezeichnern sind je nach Sprache auch bestimmte Reihenfolgen der einzelnen Elemente gewünscht. Unter Java ist dies vornehmlich folgende Reihenfolge: Konstanten, private Variablen, private Methoden, Getter und Setter und anschließend öffentliche Methoden.

Allerdings kann es valide sein, Public-Methoden und Private-Methoden zusammenzuhalten, wenn diese z. B. nach Funktionalität gruppiert sind.

Zeilenlänge und Umbrüche

Früher gab es relativ strenge Regeln, was die maximale Zeilenlänge innerhalb eines Quelltextes anging. Meist waren dies 80 Zeichen pro Zeile, bedingt durch die 80 Spalten in der Hollerith-Lochkarte von IBM. Daneben haben sich mittlerweile Zeilenlängen von 80 über 100 bis zu 120 Zeichen pro Zeile eingebürgert.

Auch in Zeiten größerer Bildschirme und höherer Auflösungen, sollten Zeilen trotzdem nicht unendlich lang gestaltet werden, sondern mit Zeilenumbrüchen gearbeitet werden. Für solche Umbrüche existieren unterschiedliche Variante, welche in gewisser Hinsicht Geschmacksache sind.

public int calculate(int valueA,
                     int valueB,
                     int valueC,
                     int valueD,
                     int valueE,
                     int valueF,
                     int valueG) {
    return 0;
}

Grundsätzlich sollten keine Umbrüche mitten in einer Parameterliste vorgenommen werden, sondern die Parameter einzeln umgebrochen werden. Auch bei Fluent Interfaces wird mit Zeilenumbrüchen gearbeitet:

CarBuilder carBuilder = new CarBuilder()
        .withWheels(4)
        .withEngine(400, Fuel.DIESEL)
        .withWindows(5)
        .build();

Die Umbrüche verbessern, richtig eingesetzt, die Lesbarkeit und Verständlichkeit des Quelltextes.

Kommentare

Für einen verständlichen Quelltext sind in vielen Fällen Kommentare in diesem nötig und wichtig.

Je nach Sprache werden unterschiedliche Möglichkeiten für Kommentare bereitgestellt. Vorwiegend sind dies Zeilenkommentare und Blockkommentare.

Blockkommentare sind eine Reihe von Kommentaren, die durch ein vorangestelltes /* und ein abschließendes */ angezeigt werden, sodass mehrere Zeilen Text zusammen kommentiert werden können. Zeilenkommentare sind Kommentare, die nur eine einzelne Zeile betreffen und mit // beginnen. Sie können am Ende einer Codezeile oder auf einer eigenen Zeile platziert werden. Beide Kommentartypen sind nützlich, um das Verständnis des Codes zu erleichtern, indem sie Erklärungen zu bestimmten Codeabschnitten bereitstellen.

In den meisten Fällen sollten innerhalb eines Quelltextes den Zeilenkommentaren der Vorrang eingeräumt werden, entweder zum Auskommentieren von Quellcode oder zum Dokumentieren innerhalb des Codes:

// Create system temporary directory
Path tmpdir = null;

// log.error(tmpdir);

Block-Kommentare werden oft für die Dokumentation von Methoden, z. B. mittels JavaDoc genutzt:

/**
 * This method returns an Optional that holds a String containing
 * the file extension of the passed filename.
 * @param filename The file name whose extension is to be determined.
 * @return Optional filled with a String with the file extension if 
 * the file has an extension, or an empty optional if it has no extension.
 */

Grundsätzlich gilt bei Kommentaren, dass sie fachlicher Natur sein sollten und dass nicht unnötig kommentiert wird. Als Sprache bietet sich hier wie bei der Benamung von Bezeichnern Englisch als kleinster gemeinsamer Nenner an. Unnötige Kommentare sollten vermieden werden:

// Calculate sum and store in sum
int sum = getSum(a, b);

Der Inhalt des Kommentars ergibt sich bereits aus der sprechenden Bezeichnung der Variablen und der dazugehörigen Methode, sodass dies nicht noch einmal mit einem Kommentar untermauert werden muss.

Interessanter wäre es hier, wenn der Kommentar noch etwas zur Fachlichkeit beiträgt:

// Calculate sums of base articles
int sum = getSum(a, b);

Auch das beliebte Auskommentieren von Code wird mittels der Sprachmittel des Kommentars ermöglicht. Im Normalfall sollte auskommentierter Quellcode am Ende immer entfernt werden und nicht im Quelltext verbleiben.

Allgemeine Regeln

Neben Regeln für spezielle Konstrukte existieren eine Reihe von allgemeinen Regeln, welche auch in Coding Conventions Einzug gefunden haben.

So gilt, dass pro Zeile genau eine Anweisung bzw. ein Statement kodiert wird, eine Funktion bzw. eine Methode genau eine Aufgabe erledigen und Klassen und Methoden eine gewisse Größe nicht überschreiten sollten.

Bei Klassen definiert sich hier meist eine maximale Größe von 2000 Zeilen, während bei Methoden gerne gesagt wird, dass eine Methode als Ganzes auf den Bildschirm passen sollte.

Aufgaben für Methoden

Auch die Beschränkung von Methoden auf eine Aufgabe ist eine sinnvolle Regel. So verheißt eine Methode mit dem Namen doItAll() schon wenig Gutes. Hingegen definiert folgende Methode:

int getSum(int a, int b)

schon anhand ihres Namens klar, welche Aufgabe sie wahrnimmt und mit welchem Ergebnis zu rechnen ist.

Dadurch, dass Funktionen bzw. Methoden sich nur auf eine Aufgabe beschränken, sind sie besser wiederverwendbar und verhindern in vielen Fällen doppelten Quelltext. Auch das Review solcher fachlich eng abgestimmten Methoden ist einfacher möglich, da die Komplexität verringert ist.

Coding Conventions

Während bis hierhin viele einzelne Elemente beschrieben wurden, sollen diese nun zu einer Coding Convention zusammengeführt werden. Solche Coding Conventions sind relativ umfangreiche Werke. In vielen Fällen ist es nicht nötig das Rad neu zu erfinden, da für viele Sprachen Standard-Konventionen existieren, welche genutzt werden können.

Alternativ sollte sich zumindest an diesen Konventionen orientiert werden. Auch die jeweiligen Entwicklungsumgebungen, setzten über die Code-Formatierung gewisse Teile von Coding Conventions direkt um.

Sprachspezifische Konventionen

Wer sich umschaut, wird feststellen, dass eine Reihe von Coding Conventions für unterschiedliche Sprachen existieren. Dies sind unter anderem die .NET: Microsoft Coding Conventions, für Java die Code Conventions for the Java Programming Language und für PHP: PSR-1 und PSR-2.

Allerdings werden manche dieser Konventionen wie für Java mittlerweile als veraltet angesehen und büßen damit auch an Verbindlichkeit ein. Bei anderen Styles wie PSR-2 werden diese direkt für die Entwicklung des Frameworks genutzt und sind somit verbindlich.

Übergreifende Konventionen

Daneben existieren noch andere Coding Conventions wie die Apple Coding Convention und der Google Style Guide.

Der Google Style Guide deckt Konventionen für unterschiedlichste Sprachen, wie C++, Objective-C, Java, Python, R, HTML, JavaScript und weitere ab und kann online eingesehen werden.

Lizenziert ist der Google Style Guide unter der Creative-Commons-Lizenz CC-BY. Neben der eigentlichen Beschreibung werden auch Dateien mit den entsprechenden Konfigurationen für die Entwicklungsumgebung mitgeliefert.

Dokumentation

Auch wenn ein Hauptaugenmerk bei Coding Conventions auf dem Quelltext liegt, sollte die Dokumentation ebenfalls beachtet werden. So sollte nur das notwendige dokumentiert und tote und inkorrekte Dokumentation gelöscht werden.

Auch hat es sich eingebürgert, eine entsprechende Datei ins Wurzelverzeichnis des Projektes zu legen. Diese trägt meist den Namen README bzw. README.md

In diesem Dokument wird erklärt, um welches Projekt es sich handelt und ein kurzer Überblick über das Projekt gegeben. Daneben werden weiterführende Links bereitgestellt und erklärt, wie das Projekt gebaut werden kann.

# WordPress2Markdown

WordPress2Markdown is a tool that convert WordPress eXtended RSS (WXR) into markdown. Export the WordPress site via
backend and use the WordPress eXtended RSS (WXR) with this tool.

## Usage

WordPress2Markdown is a command line tool.

> java -jar WordPress2Markdown.jar -i wordpress-export.xml -s DATETIME -o /home/seeseekey/MarkdownExport

### Parameter

The options available are:

    [--author -f value] : Filter export by author
    [--authors -a] : Export authors
    [--help -h] : Show help
    [--input -i value] : Input path
    [--output -o value] : Output path
    [--scheme -s /POST_ID|DATETIME/] : Scheme of filenames

## Conversion

WordPress2Markdown converted the following html and other tags:

* \<em\>
* \<b\>
* \<blockquote\>
* \<pre\>
* \<img\>
* \<a\>
* Lists
* WordPress caption blocks ()

All other tags are striped.

## Developing

Project can be compiled with:

> mvn clean compile

Package can be created with:

> mvn clean package

## Authors

* seeseekey - https://seeseekey.net

## License

WordPress2Markdown is licensed under AGPL3.

Eine weitere wichtige Datei ist das Changelog, bzw. die Datei CHANGELOG.md. Diese Datei dokumentiert Änderungen am Projekt und informiert den Leser somit über Änderungen, neue Funktionalität und Ähnliches.

# Changelog

This changelog goes through all the changes that have been made in each release.

## [1.2.0-SNAPSHOT]() - 2022-03-04

### Added

* Implement simple conversion for CSV files

### Changed

* Update project to Java 17
* Rework changelog
* Update dependencies
* Change license from GPL3 to AGPL3

### Fixed

* Fix some SonarLint code smells
* Small optimizations

## [1.1.0](https://github.com/seeseekey/Convert2Markdown/releases/tag/v1.1) - 2019-10-13

### Added

* Implement conversion of MediaWiki dump files
* Add statistical information for export
* Add support for exporting author (#1)
* Add filter to export only a specific author

### Changed

* Rename tool to Convert2Markdown
* Update documentation
* Rebuild HTML to markdown conversion with HTML parser

## [1.0.0](https://github.com/seeseekey/Convert2Markdown/releases/tag/v1.0) - 2019-03-26

* Initial release

Versionierung

Im weiteren Sinne gehört auch die Versionierung des Projektes zu den Coding Conventions. Gerne genutzt wird hierbei die semantische Versionierung. Dabei liegen den Zahlen der Versionnummer z. B. 2.4.7 eine bestimmte Bedeutung zugrunde.

So handelt es sich bei der ersten Zahl um die Major-Version, welche nur dann erhöht wird, wenn zur Vorgängerversion inkompatible Änderungen oder andere signifikanten Änderungen vorgenommen wurden.

Die zweite Zahl ist die sogenannte Minor-Version, welche meist bei neuer Funktionalität hochgezählt wird. Die letzte Zahl bezeichnet die Bugfix-Version und wird bei entsprechenden Fehlerbereinigungen hochgezählt.

Daneben existieren auch andere Versionierungen, wie das relativ beliebte Schema Jahr.Monat z. B. 2023.04 als Versionnummer, welche bei neuen Releases basierend auf der Version gerne um eine dritte Nummer erweitert werden z. B. 2023.04.1.

Umsetzung

Neben der eigentlichen Definition einer Coding Conventions ist es wichtig, dass diese im Entwicklungsalltag berücksichtigt und genutzt wird. Hier stellt sich dann die Frage nach der organisatorischen Umsetzung.

Grundlegend sind es einige Schritte auf dem Weg bis zu Nutzung und Umsetzung. So sollte sich im ersten Schritt auf eine Coding Convention geeinigt werden. Nachdem dies geschehen ist, mitsamt aller diesbezüglicher Regeln, wie zur Benennung oder der gewünschten Komplexität, müssen diese Coding Conventions entsprechend kommuniziert werden.

So ist es problemlos möglich, entsprechende Templates für die Einstellungen der jeweiligen IDEs zur Verfügung zu stellen. Auch sollte die Überprüfung der Coding Conventions beim Review kontrolliert werden.

Daneben können die entsprechenden Coding Conventions auch per Software überprüft und z. B. das Pushen in ein entferntes Git-Repository nur erlaubt werden, wenn die Coding Conventions eingehalten wurden. Allerdings sollte auch nicht versucht werden, soziale Probleme, welche sich bei der Einführung der Konventionen ergeben, durch rein technische Ansätze zu lösen.

Umstellung

Eine weitere Frage ist die Umstellung der bestehenden Projekte auf neue Coding Conventions. Bestimmte Dinge wie die Formatierung des Quelltextes können meist automatisch auch für größere Projekte bewerkstelligt werden.

Daneben sollte bestehender Code Stück für Stück auf die Konventionen angepasst werden, z. B. bezüglich der Benamung. Dies kann immer dann geschehen, wenn an einer entsprechenden Stelle im Rahmen einer Anforderung gearbeitet wird.

Probleme

Natürlich kann es bei der Nutzung und Einführung von Coding Conventions Probleme geben. Dies kann sich in Widerstand aus der Entwicklerschaft oder in Problemen mit der technischen Seite wie unterschiedlicher IDEs ausdrücken.

Vor allem bei einer Neueinführung kann es schwierig sein, sich an entsprechende Konventionen und Regeln zu gewöhnen, wenn vorher ohne gearbeitet wurde. Das Gleiche gilt, wenn eine Konvention nicht den eigenen Präferenzen entspricht.

Es kann passieren, dass einige Zeit dafür aufgebracht werden muss, die Konventionen zu verinnerlichen und umzusetzen. Deshalb ist es wichtig, die Konventionen klar zu kommunizieren, ihre Nutzung verpflichtend zu machen und dies im Entwicklungsprozess wie beim Review auch zu beachten.

Fazit

Coding Conventions sind ein wesentlicher Bestandteil der Softwareentwicklung und bieten viele Vorteile. Sie helfen dabei, Quelltexte einfacher lesbar, verständlich und wiederverwendbar zu machen. Dadurch wird die Wartbarkeit verbessert und die Qualität der Software erhöht. Dies kann zu einer höheren Produktivität und einem schnelleren Entwicklungsprozess führen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

JSON mit Schlüsselwörtern unter Java deserialisieren

Mittels GSON von Google, können JSONs unter Java einfach in Objekte deserialisiert werden. Allerdings können bestimmte JSON-Objekte zu Problemen führen. So zum Beispiel folgende JSON-Datei:

{
   "default":"ABC",
   "value":"DEF"
}

Das entsprechende Java-Objekt könnte in diesem Fall wie folgt aussehen:

class Data {

  public String default;
  public String value;
}

Damit wäre GSON in der Lage die entsprechenden Felder aus dem JSON, den Felder in der Klasse zuzuordnen. Allerdings kann obige Klasse nicht kompiliert werden. Hintergrund hierfür ist das Feld default. Unter Java ist dies ein Schlüsselwort und kann somit nicht als Feldname genutzt werden. Unter Sprachen wie C# könnte hier mit einer Verbatim-Zeichenkette gearbeitet werden:

public String @default;

Allerdings bietet Java diese Möglichkeit nicht an, sodass sich hier anders beholfen werden muss. Die Lösung ist die Annotation SerializedName. Diese gibt den Namen des Schlüssels im JSON an, welcher in das entsprechende Feld deserialisiert werden soll:

class Data {

  @SerializedName("default")
  public String defaultValue;
  public String value;
}

Damit kann GSON die Serialisierung wieder vornehmen und das obige JSON kann in eine entsprechende Java-Struktur abgebildet werden.

Der universelle Cyberdelfin

Funktechniken wie NFC, RFID und Frequenzen wie die Nutzung des 433 MHz-Bandes bleiben den meisten Interessierten verschlossen. Mit dem Flipper Zero, welcher nun auch in Europa ausgeliefert wird, soll sich dies ändern.

Vor knapp zwei Jahren wurde im Rahmen einer Kickstarter-Kampagne im Juli 2020 der Flipper Zero angekündigt, auch Golem.de berichtete darüber.

Beim Flipper Zero handelt es sich um einen Hacker-Tamagotchi bzw. eine Art Funk-Multitool für Hacker. Die grundsätzliche Idee war es, die benötigten Werkzeuge für das Pentesting bestimmter Technologien, welche vorwiegend in der physischen Welt Verwendung finden, in einem Gehäuse zu vereinen. Dadurch ist der Anwender wesentlich mobiler und kann entsprechende Tests auch unauffällig durchführen.

Der Flipper Zero in Aktion

Im Grunde handelt es sich um ein Bündel unterschiedlichster Funktionalitäten, mit denen der Flipper Zero unter anderem als Universalfernbedienung, NFC- und RFID-Kopierstation (soweit technisch möglich), oder als Bastelwerkzeug für Hardwareinteressierte genutzt werden kann.

Nachdem die Kickstarter-Backer in Amerika und Australien bereits beliefert wurden, steht jetzt Europa auf der Liste.

Vom Hackspace zur Idee

Die Idee des Flipper Zero kam im Umfeld des Neuron Hackspace auf. Der Neuron Hackspace versteht sich als der erste Hackspace in Moskau, welcher von einem Besuch des 29C3 in Berlin inspiriert, schließlich im Juni 2011 seine Tore in Moskau öffnete.

In diesem mittlerweile geschlossenen Hackspace, kam die Idee für den Flipper Zero und den Flipper One auf. Die ursprüngliche Idee für die Geräte stammte von Pavel Zhovner, während Alexander Kulagin die Projektleitung übernahm und sich Valeria Aquamain als Art Director verantwortlich zeichnete.

Ursprünglich sollte ein Raspberry Pi Zero W als Grundlage genutzt werden. Von dieser Idee wurde Abstand genommen, da das Modul nicht in ausreichenden Stückzahlen geliefert werden konnte und die entsprechenden Compute-Module zu teuer gewesen wären.

Die Idee dahinter war, bestimmte Funktionalitäten in separater Hardware zu implementieren und den Raspberry Pi Zero W mit einer Linux-Distribution für anspruchsvollere Aufgaben zu betreiben.

Diese Variante erhielt den Namen Flipper One. Die Variante ohne entsprechende Linux-Möglichkeiten wurde schließlich zum Flipper Zero. Die Arbeit am Flipper One wurde zugunsten der Flipper Zero zurückgestellt.

Nachdem die Macher des Flipper Zero knapp 12.000 Vorbestellungen erhalten hatten, folgte eine entsprechende Kickstarter-Kampagne.

Die ursprünglich für das Hauptziel vorgesehenen 60.000 US-Dollar waren bereits nach acht Minuten ausfinanziert und 28 Tage später waren 4,4 Millionen US-Dollar erreicht und schlussendlich wurden über 4,8 Millionen US-Dollar eingesammelt.

Aufgrund der eingesammelten Summe wurden auch einige vorher als optional betrachtete Features mit in das Gerät aufgenommen. Dazu zählen ein alternativer dunkler Farbton, Bluetooth und NFC.

Designprozess

Für das Design, insbesondere das sogenannte Design for manufacturability (DFM), wurde mit der Firma Design Heroes zusammengearbeitet, welche ebenfalls in Moskau ansäßig sind. Beim DFM liegt der Fokus darauf, das Design des Produktes so zu gestalten, dass es in der Produktion keine größeren Probleme verursacht und einfach herzustellen ist.

Daneben unterstützte Design Heroes die Macher des Flipper Zero von den ersten Sketchen über die 3D-Modelle bis zu den ersten Prototypen, welche im 3D-Druck entstanden.

Während des Designprozesses wurden unterschiedlichste Änderungen vorgenommen, so wanderte z. B. der IR-Transceiver von der oberen Seite des Gerätes an die Seite. Grund hierfür war, dass der Transceiver auf der Oberseite oft verdeckt war, entweder durch Finger oder entsprechende Boards, welche mit der GPIO-Leiste genutzt wurden. Auch das Layout der GPIO-Leiste änderte sich einige Male, bis es seine jetzige Form erhielt.

Ebenfalls erst im Laufe des Design- und Umsetzungsprozesses, erfolgte die Erweiterung des Gerätes um einen microSD-Slot, um Dinge wie Code-Datenbanken und Ähnliches zu speichern, welche im 1 Megabyte großen Flash-Speicher des Gerätes selbst keinen Platz finden würden.

Während des Prozesses wurden immer wieder Anpassungen an der Hardware und der entsprechenden Verdrahtung gemacht. So wurde unter anderem die Batterie mit einem entsprechenden Konnektor versehen, damit diese einfach wechselbar ist, falls der Akkumulator mit der Zeit nicht mehr die gewünschte Leistung liefert.

Produktion

Bei der Ankündigung des Flipper Zero war von einer Auslieferung im Februar 2021 die Rede, was aus unterschiedlichsten Gründen nicht eingehalten werden konnte. Allerdings war dies aus Sicht eines Backers nicht weiter tragisch, was auch der exzellenten Kommunikation des Teams hinter dem Gadget zu verdanken ist.

So gab es für die Backer und andere Interessierte einen tiefen Einblick in die Probleme bei der Entwicklung und der Produktion. Prozesse wie die Herstellung der Gehäuse per Spritzguss wurden erklärt und die Herausforderungen dabei beschrieben. Die späteren Schritte wie der Test der Hardware wurden ebenfalls ausführlich beleuchtet.

Auch in diesem Projekt gab es Probleme im Zusammenhang mit der Chipkrise, sodass sich bestimmte Bestellungen für Bauteile, wie dem Bildschirm, verzögerten. Das führte auch dazu, dass einige Redesigns vorgenommen werden mussten, um nicht lieferbare Komponenten zu ersetzen.

So erwies es sich zeitweise als schwierig weitere ICs für das Laden der Batterie zu erhalten, der eingesetzte BQ25896RTWR war nicht mehr zu beschaffen, was für entsprechende Verzögerungen sorgte.

Erster Eindruck

Je nach getätigter Bestellung kann und wird der Flipper Zero mit entsprechendem Zubehör wie der Silikonhülle geliefert.

Der Flipper Zero selbst, wird in einer kleinen Pappbox geliefert. Wer diese öffnet, erhält einen Blick auf eine kurze Anleitung, sowie einen Aufkleber.

Darunter befindet sich ein USB-C-Kabel, welches mitgeliefert wird, sowie eine Ebene tiefer der eigentliche Flipper Zero. Das Gerät selbst misst 100 × 40 × 25 mm und wiegt 102 Gramm und liegt damit angenehm in der Hand.

Der Flipper Zero im Außeneinsatz

Allerdings wirkt es zumindest in der Vorstellung des Autors etwas größer als die Produktfotos es erahnen ließen.

Gefertigt wird das Gehäuse aus Polycarbonat, ABS-Kunststoff und Polymethylmethacrylat, besser bekannt unter dem Namen Acrylglass. Spezifiziert ist das Gerät für eine Betriebstemperatur von 0 bis 40 Grad.

Bildschirm

Der Flipper Zero verfügt über ein 1.4 Zoll (3,56 Zentimeter) großes Display, mit einer Auflösung von 128 × 64 Pixeln. Der Bildschirm ist ein klassisches LCD bei einem Stromverbrauch von 400 nA, wenn das Backlight deaktiviert ist. Intern ist dieser Bildschirm per SPI angebunden.

Der Bildschirm selbst ist beim Flipper immer aktiviert, nur die Hintergrundbeleuchtung wird entsprechend zugeschaltet.

Die Wahl des Bildschirmes war für den Flipper Zero eine zentrale Entscheidung, so wurde praktisch das gesamte Gerät um den Bildschirm herum gebaut. In der Überlegung stand auch ein E-Ink-Display, allerdings wurden hier die Aktualisierungsraten als zu gering bewertet und sich stattdessen für ein entsprechendes LCD entschieden.

Überblick

Gesteuert wird das Gerät über eine Art Steuerkreuz, inklusive Mitteltaste, sowie dem Zurück-Button. Neben dem Bildschirm ist eine Status-LED verbaut.

Der Flipper ist der Verpackung entstiegen

An der Oberseite des Gehäuses befindet sich eine GPIO-Leiste zur Ansteuerung externer Hardware. Sie wird mit 3,3 Volt betrieben, ist aber 5 Volt tolerant. Die Schräge auf der linken Seite enthält den Infrarot-Transceiver.

Auf der Unterseite befindet sich der Slot für die microSD-Karte. Dieser wird unter anderem für die Datenbanken benötigt, welche die Firmware des Flipper Zero nutzt.

Auf der rechten Seite befindet sich die USB-C-Buchse, mit welcher das Gerät geladen und mit einem Rechner verbunden werden kann.

Zwischen dem microSD-Slot und der USB-C-Buchse findet sich noch eine Öse, an welcher ein Band befestigt werden kann. Mitgeliefert wird ein solches Band allerdings nicht.

Das Herz der Maschine

Herz des Flipper Zero ist der STM32WB55, einem Mikrocontroller von STMicroelectronics. In diesem befindet sich ein ARM Cortex M4, welcher mit 64 MHz getaktet ist und als Applikationsprozessor dient, sowie ein ARM Cortex-M0+ welcher mit 32 MHz getaktet ist und als Netzwerkprozessor dient. Daneben verfügt der Mikrocontroller über 1 Megabyte Flashspeicher und 256 KByte SRAM.

In der Theorie sollte der Flipper Zero mit einer Batterieladung ungefähr 30 Tage durchhalten. So zumindest die Aussage während der Kickstarter-Kampagne. Mittlerweile werden sieben Tage Laufzeit angegeben. Es handelt sich um eine LiPo-Batterie mit einer Kapazität 2000 mAh. Geladen wird diese über den USB-C-Anschluss des Flipper Zero.

Im Gerät selbst sind eine Vielzahl an meist drahtlosen Schnittstellen implementiert. Im Kontext des Gerätes werden diese auch als Subsysteme bezeichnet.

Sub-Ghz-System

Der Flipper-Zero besitzt eine Antenne für Frequenzen unterhalb eines Gigahertz, welche in Verbindung mit dem CC1101-Chip genutzt wird. In der Terminologie des Gerätes ist dies das sogenannte Sub-Ghz-System. Innerhalb dieses Frequenzbereiches bewegen sich eine Reihe von Geräten, wie Garagentore, Autoschlüssel, mehr oder weniger smarte IoT-Geräte, wie schaltbare Steckdosen, was nicht weiter verwunderlich ist, da ein Teil der Frequenzen unterhalb eines Gigahertz zu den ISM-Bändern gehören.

Auch wenn das System als Sub-Ghz-System bezeichnet wird, bedeutet dies nicht, dass mit dem Flipper Zero alle Frequenzen unterhalb eines Gigahertz genutzt werden können.

Der CC1101 von Texas Instruments wird als sparsamer Transceiver angeboten. Er unterstützt die Frequenzbänder 300–348 MHz, 387–464 MHz und 779–928 MHz. Damit stehen auch nur diese Frequenzen im Sub-Ghz-System zur Verfügung.

Im Flipper Zero befindet sich auch ein Frequenzscanner; mit dem innerhalb dieser Bänder ermittelt werden kann, auf welcher Frequenz das System sendet. Dazu wird der entsprechende Sender aktiviert, während der Frequenzscanner läuft.

Der Frequenzscanner in Verbindung mit einem Autoschlüssel

Signale können im Sub-Ghz-System auch roh aufgezeichnet werden. Allerdings sollte beachtet werden, dass es sich beim Flipper Zero nicht um ein Software Defined Radio (SDR) handelt und somit das Signal bei der Rohaufzeichnung nicht immer komplett aufgezeichnet wird.

RFID

Neben dem Sub-Ghz-System, werden 125 kHz RFID-Tags, welche auch als Low Frequency-Tags bekannt sind, unterstützt. Der Flipper Zero unterstützt mehrere Modulation, wie Amplitudenmodulation, Phasenumtastung und Frequenzumtastung im Zusammenhang mit diesen Tags.

Zu den unterstützten Karten zählen EM400x, EM410x, EM420x, HIDProx, Indala. Diese werden unter anderem zur Zugangskontrolle genutzt. Solche Karten können mit dem Flipper einfach ausgelesen und geklont werden.

Near Field Communication

Im Rahmen der erfolgreichen Kickstarter-Kampange kam die Unterstützung für Near Field Communication, kurz NFC hinzu, was das Gerät in diesem Bereich abrundet.

Bei RFID sind eine Reihe von Frequenzbereichen definiert, das Band zwischen 125 und 134,2 kHz (Low Frequency), das Band auf 13,56 MHz (High Frequency) und das Band zwischen 856 und 960 MHz (Ultra High Frequency).

NFC setzt ebenfalls auf der Frequenz 13,56 MHz auf und nutzt diese für entsprechende Übertragungen über kurze Entfernungen von wenigen Zentimetern.

Während RFID auf hohe Reichweite optimiert ist, meist primitive Protokolle nutzt, keine bzw. wenig Sicherheit bietet, sieht dies bei NFC-Tags anders aus. Hier wird auf komplexere Protokolle und kryptografische Absicherung gesetzt.

Im Gegensatz zu RFID ist bei NFC der bidirektionale Datenaustausch zwischen zwei Geräten möglich. Hier unterstützt das Gerät aktuell unterschiedlichste Standards, wie ISO-14443A/B, NXP Mifare® Classic/Ultralight/DESFire, FeliCa™ und die NFC Forum-Protokolle.

Damit ist das Gerät zu einer Vielzahl an Karten, wie Kreditkarten und dem Personalausweis kompatibel. Auch Zugangschips, wie sie in vielen Gebäuden benutzt werden, können ausgelesen werden. Je nach Möglichkeit wird nach der generellen Erkennung einer Karte; die Bearbeitung in einer speziellen Applikation innerhalb der Firmware vorgeschlagen.

Die UID wurde ausgelesen

Wird z. B. ein Mifare Classic eingelesen, so können anschließend mit der entsprechenden App die Schlüssel ausgelesen werden.

Auch Amiibos können emuliert werden

Grundsätzlich beherrscht der Flipper Zero bei allen Subsystemen nicht nur das Auslesen der Informationen, sondern auch die Emulation z. B. die entsprechender NFC-Tags. So ist z. B. die Emulation von Amiibos für die Nintendo Switch ohne Probleme möglich.

Bluetooth

Eine weitere Funktechnik, die der Flipper Zero beherrscht, ist Bluetooth Low Energy in Version 5, bei einer Datenrate von 2 Mbps.

Bluetooth muss hierbei in den Einstellungen der Flipper aktiviert werden, anschließend kann es unter anderem dafür genutzt werden sich mit der mobilen App zu verbinden.

Daneben befindet sich unter den Plugins eine Beispielapplikation zur Nutzung als Bluetooth-Fernbedienung.

Infrarot

Infrarot ist nicht erst seit dem Start des James-Webb-Teleskops in aller Munde. Der Flipper Zero verfügt über einen Infrarot-Transceiver zum Senden und Empfangen entsprechend kodierter Signale. Der Transceiver arbeitet bei einer Wellenlänge von 800 bis 950 nm.

In der Firmware selbst wird hierfür eine Applikation mitgeliefert, welche als eine Art Universalfernbedienung fungiert und per Wörterbuch-Attacke alle entsprechenden IR-Codes sendet, um den Kanal zu wechseln oder das Gerät abzuschalten. Damit wäre es beispielhaft möglich im Elektronikmarkt alle Fernseher abzuschalten; auch wenn es sicherlich sinnvollere Varianten der Nutzung gibt.

iButton

Eine kontaktbehaftete Schnittstelle, welche vom Flipper Zero unterstützt wird, ist die iButton-Schnittstelle. Diese auch als Dallas Touch Memory bekannte Technik wird z. B. zur Zugangskontrolle in Gebäuden benutzt.

Die Kontaktpunkte für die Schnittstelle

Hierbei wird der iButton auf eine entsprechende Schnittstelle gelegt und ein mechanischer und elektrischer Kontakt hergestellt. Anschließend findet die Kommunikation über 1-Wire statt.

Hierfür wurde am Flipper Zero eine Kontaktmöglichkeit auf der Unterseite des Gerätes geschaffen, mit welcher die entsprechende Hardware ausgelesen, beschrieben und emuliert werden kann. Unterstützt werden die Protokolle CYFRAL und Dallas DS1990A.

GPIO

Die Einsatzmöglichkeiten des Flipper Zero sind nicht nur auf Funktechnologien beschränkt. Über die GPIOs, welche sich oben am Gehäuse befinden, kann das Gerät mit externer Hardware verbunden werden.

Die GPIO-Leiste des Flipper Zero

Damit ist es möglich den Flipper für das Flashen von Hardware oder das Debugging und Fuzzing zu benutzen. Über diese Funktionalität kann das Gerät auch als USB-UART-Bridge genutzt werden.

Der Flipper Zero unterstützt die Spannungen 3,3 und 5 Volt, wobei letztere in den Einstellungen aktiviert werden muss. Pro Pin werden maximal 20 mA geliefert.

Im Shop des Herstellers werden unter anderem Entwicklungsboards mit Wi-Fi und entsprechende Prototyping-Boards angeboten.

Visuell, Taktil und Musikalisch

Neben dem Bildschirm gibt der Flipper Zero über eine LED, einen Buzzer, sowie per Vibration Rückmeldung an die Außenwelt und den Nutzer. Der eingebaute Buzzer arbeitet in einer Frequenz von 100 bis 2500 Hz, bei einer maximalen Lautstärke von 87 dB.

Das Plugin MusicPlayer auf dem Flipper Zero

Er kann mit der in der Firmware integrierten Musik-App getestet werden. In den Einstellungen kann die Lautstärke generell auf null reduziert werden, sodass das Gerät auch weniger auffällig benutzt werden kann.

Bad USB und U2F

Über den USB-Port, kann das Gerät zum Pentesting per USB genutzt werden. Diese als Bad USB firmierte Technik, emuliert eine USB-Tastatur und kann entsprechende Skripte ausführen. Dazu wird das gewünschte Skript ausgewählt und das Gerät an den Rechner der Wahl angeschlossen.

Als Skriptsprache wurde Ducky Script implementiert, sodass eventuell vorhandene Skripte übernommen werden können. Bekannt ist Ducky Script durch Rubber Ducky, einem Keystroke-Injection-Tool.

Genutzt wird diese Funktionalität z. B. bei Sicherheitsüberprüfungen von Unternehmen, bei welchen als gewöhnliche USB-Sticks getarnte Bad USB-Geräte vor oder im zu testeten Unternehmen platziert werden. Die Hoffnung ist es, dass der Finder dieser Sticks diese am Arbeitsrechner anschließt und damit die entsprechenden Skripte zur Ausführung bringt.

Natürlich kann das Ganze auch für unlautere Zwecke genutzt werden. Damit handelt sich um eine der vielen Dual-Use-Funktionalitäten des Flipper Zero.

Daneben gibt es Unterstützung für U2F, also für eine entsprechende Zwei-Faktor-Authentifizierung, wie sie z. B. auch mit dem YubiKey umgesetzt wird.

Einrichtung

Nachdem der Flipper Zero ausgepackt wurde, kann mit der Ersteinrichtung begonnen werden. Der Flipper Zero verfügt über einen microSD-Port, in welchem eine entsprechende microSD-Karte hinterlegt werden sollte. Bei zu kurzen Fingernägeln, kann der Vorgang des Einsetzten der Karte etwas unpraktisch sein, ist aber mit etwas Geschick zu bewerkstelligen.

In der Theorie funktioniert das Gerät auch ohne eine entsprechende microSD-Karte, allerdings ist die Praktikabilität etwas eingeschränkt, da auf der microSD-Karte entsprechende Datenbanken und Ähnliches gespeichert werden.

Eine microSD-Karte wird nicht mitgeliefert. Bei der Wahl der Karte sollte auf Karten von Markenherstellern gesetzt werden. Hintergrund ist, dass der Flipper Zero per SPI-Modus auf die Karten zugreift, während bei einem Rechner im Normalfall mit dem SDIO-Modus gearbeitet wird.

Bei günstigen microSD-Karten ist die Unterstützung für den SPI-Modus in vielen Fällen fehlerhaft oder unzureichend implementiert und kann zu Problemen führen.

Unterstützt werden microSD-Karten bis zu einer Kapazität von 128 GB, allerdings genügt in den meisten Fällen eine Karte mit einer Kapazität von 16 oder 32 GB. Die microSD-Karte für den Flipper Zero kann FAT32 oder exFAT formatiert sein.

Die Formatierung kann auch über das Gerät selbst vorgenommen werden, sodass hier keinerlei Vorbereitung am Rechner notwendig ist. Dabei wird die microSD-Karte bis zu einer Größe von 32 GB mit FAT32 formatiert, darüber hinaus mit exFAT.

Firmware-Update

Da der Flipper Zero mit einer relativ alten Firmware ausgeliefert wird, sollte im ersten Schritt die entsprechende Firmware aktualisiert werden. Dazu soll laut Anleitung die Webseite update.flipperzero.one besucht werden, welche die entsprechenden Möglichkeiten des Updates aufzeigt.

Angeboten werden zwei Möglichkeiten, das Gerät zu aktualisieren. Bei der ersten Möglichkeit wird die Applikation qFlipper genutzt, welche als Desktop-Anwendung unter Linux, macOS und Windows zur Verfügung steht.

Daneben existiert mittlerweile auch die Möglichkeit das Gerät über die entsprechende mobile App (iOS, Android) zu aktualisieren. Allerdings steht diese Möglichkeit erst neueren Firmware-Versionen zur Verfügung, sodass bei der Erstaktualisierung die qFlipper-Applikation genutzt werden muss.

‎Flipper Mobile App
‎Flipper Mobile App
Price: Free
Flipper Mobile App
Flipper Mobile App
Price: Free

Neben diesen beiden Methoden wird unter my.flipp.dev an einer Methode gearbeitet, die Aktualisierung über den Browser vorzunehmen. Diese wird allerdings noch als experimentell eingestuft und sollte nicht genutzt werden.

Das Firmware-Update wird durchgeführt

Nachdem Start der Applikation kann der Flipper Zero mit dem Rechner verbunden werden. Wurde dieser erkannt, kann das Update gestartet werden.

qFlipper weist auch darauf hin, ob eine microSD-Karte im Gerät erkannt wurde. Auch ohne microSD-Karte kann die Firmware-Aktualisierung vorgenommen werden. Wird später eine entsprechende Karte im Gerät installiert, können die entsprechenden Datenbanken ebenfalls über qFlipper auf diesem installiert werden.

Die eigentliche Aktualisierung selbst dauert nur knapp eine bis zwei Minuten und ist relativ schnell abgeschlossen. Damit ist das Gerät einsatzbereit und kann genutzt werden.

Der grüßende Delfin

Am Anfang begrüßt der Cyberdelfin den Nutzer und bedankt sich unter anderem für die Unterstützung auf Kickstarter. Anschließend kann das Gerät genutzt werden.

Der Delfin bedankt sich für die Unterstützung

Der Delfin ist hierbei eine Anspielung auf die Kurzgeschichte Johnny Mnemonic, von William Gibson, in welcher ein entsprechender Cyberdelfin mit dem Namen Jones vorkommt.

Die Steuerung erfolgt, wie oben erwähnt, über das Steuerkreuz und den Bestätigungs- bzw. Zurück-Button.

Mit einem Druck des Rechts-Button wird der Pass des Cyberdelfins angezeigt. Der Cyberdelfin ist ein elementarer Bestandteil des Flipper Zero und soll eine Art Tamagotchi-Erlebnis liefern. Neben einem Namen, der automatisch für das Gerät vergeben wird, verfügt der Delfin über ein Level, das aktuell bis Level 3 gesteigert werden kann. Dieses Level steigt mit der Nutzung Flipper Zero. Daneben verfügt der Delfin über eine Gemütslage, von Glücklich zu Okay bis hin zu Schlecht. Der Name wird bei der Produktion fest vergeben. Dazu wurde ein neuronales Netz mit den Namen der Pokémon trainiert.

Ein Druck auf den Oben-Button führt zum Sperrmenü des Flipper Zero. In diesem kann das Gerät gesperrt werden, eine PIN gesetzt und in der Theorie der sogenannte DUMB mode aktiviert werden.

In diesem noch nicht implementierten Modus, soll das Gerät nur noch Spiele spezifische Funktionalität anzeigen und somit wie ein Spielzeug aussehen, falls es einmal unauffälliger zugehen soll.

Die Links- und Unten-Buttons können im Menü frei belegt werden und sind im Auslieferungszustand mit dem Sub-Ghz-System und dem NFC-System belegt.

Ein Druck auf die mittlere Taste öffnet das Menü. Neben dem Zugriff auf die unterschiedlichen Subsysteme finden sich hier die Einstellungen und die Plugins. Eines der Plugins ist das Spiel Snake, sodass Freunde eines alten Nokia-Telefons auf ihre Kosten kommen.

In den Einstellungen können Informationen zur Hardware eingesehen werden, das System konfiguriert und Informationen über den genauen Stromverbrauch des Gerätes ermittelt werden.

Neben der Bedienung über das Menü- bzw. das Steuerkreuz gibt es einige Spezialkombinationen. Für einen Neustart z. B. wird das Steuerkreuz nach links gedrückt und gleichzeitig die Zurück-Taste für einige Momente gedrückt. Der Neustart ist nach knapp zwei Sekunden abgeschlossen und das Gerät kann dann wieder genutzt werden.

Kompanion-Applikationen

Bei Firmware-Upgrade wurde bereits erläutert, dass es für den Flipper Zero unterschiedliche Applikationen existieren. Diese sollen noch einmal kurz im Detail beleuchtet werden.

qFlipper

Die Applikation qFlipper, dient unter anderem der Aktualisierung des Gerätes. Daneben können dort Informationen über die Firmware und die Datenbanken ermittelt werden.

qFlipper bietet ein Update an

Was die Firmware-Aktualisierungen betrifft, ermöglicht qFlipper die Auswahl der entsprechenden Channels, sodass der Flipper Zero auch mit der Entwicklungsfirmware bespielt werden kann.

Auch ein Zugriff auf die microSD-Karte ist über qFlipper möglich, sodass über diesen Weg Dateien auf die microSD-Karte gelegt werden können oder von dort heruntergeladen werden können.

Der Quelltext der App ist auf GitHub verfügbar und unter der GPL3 lizenziert und damit freie Software. Technisch handelt es sich um eine in C++ geschriebene Applikation, welche das Qt-Framework nutzt.

App für Mobilgeräte

Neben qFlipper existieren für iOS und Android entsprechende mobile Apps. Mit dieser kann die Firmware ebenfalls aktualisiert werden und es können interne Informationen über das Gerät eingesehen werden.

Über die mobilen Apps können unter anderem die ausgelesenen Schlüssel verwaltet werden

Ein wichtiges Feature der Applikation ist die Verwaltung eingelesener Schlüssel und Ähnlichem. Über den Archive-Tab der Applikationen können diese bequem verwaltet und entsprechend benannt werden.

Zwar verfügt der Flipper Zero über eine Bildschirmtastatur, über welche die Schlüssel benannt werden können, allerdings ist dies mit den mobilen Applikationen wesentlich angenehmer.

Auch das Streaming des Bildschirminhaltes des Flipper Zero, z. B. für Screenshots, ist mit der App möglich. Genau wie die qFlipper-Applikation enthalten die mobilen Apps einen Dateimanager, um auf den internen und externen Speicher des Flipper Zero zuzugreifen.

My Flipper

Neben diesen nativen Applikationen existiert mit My Flipper eine Webapplikationen, welche aktuell nur im Browser Chrome funktioniert. Geschuldet ist dies der Nutzung der Web Serial API.

Die Webapplikation My Flipper

Über die Webapplikation, können Spielereien vorgenommen werden, z. B. die Nutzung des Flippers als Ausgabegerät für Zeichnungen, welche in der Webapplikation vorgenommen werden oder auf die Kommandozeile zugegriffen werden.

Kommandozeile

Dies funktioniert auch per Terminal z. B. unter macOS. Dazu muss nach dem Anschluss des Flipper Zero das entsprechende Gerät ermittelt werden:

ls /dev/cu.usbmodemflip*

Nun kann sich mit dem Gerät verbunden werden:

screen /dev/cu.usbmodemflip_Uchfun1

Über die Kommandozeile können unter anderem die GPIO-PINs gesteuert werden.

Dokumentation und Community

Mit docs.flipperzero.one verfügt der Flipper Zero über eine entsprechende Dokumentation, welche im Moment allerdings noch an vielen Stellen lückenhaft oder nicht vorhanden ist.

Wohl unter anderem deshalb sucht Flipper Devices nach einem Technical Writer.

Allerdings hilft die Community bei vielen Fragen rund um das Gerät weiter. Neben dem offiziellen Forum existiert ein entsprechender Discord-Server.

Eine weitere Auflistung rund um die Community und interessanter Projekte rund um den Flipper Zero findet sich bei Awesome Flipper, welches sich als guter Einstiegspunkt anbietet.

Die offiziellen Applikationen rund um den Flipper Zero, sowie die Firmware sind auf GitHub verfügbar. Die mobilen Applikationen sind unter der MIT-Lizenz, qFlipper und die Firmware unter der GPL3 lizenziert und damit freie Software.

Made in Russia

Mit dem Projekt, wurde die Firma Flipper Devices Inc., nach US-amerikanischem Recht gegründet und registriert, bei welcher es sich, zumindest was den Sitz in den USA angeht, um eine Briefkastenfirma handelt.

Das eigentliche Büro des Projektes bzw. der Firma befindet sich Moskau. Mit der Invasion der Ukraine stellte sich die Frage, ob die Geräte aufgrund der politischen Lage noch ausgeliefert werden. Das Team formulierte seine Gedanken und die entsprechenden Informationen darüber klar:

Our team consists of both Ukrainians and Russians. And all of us have friends and relatives on both sides. We are all very worried about the ongoing events and consider it necessary to speak out.

We are radically against the ongoing „special military operation*“ and none of our team members support it. All sensible Russian-speaking professionals in the IT industry adhere to the same opinion.*

We want to live and develop in a peaceful, professional, and competitive environment where the main values are honesty, common sense, laws, and human rights. Where contracts are respected, institutions work, and international business can be created.

Current events will not affect the Flipper Zero production in any way, and all ordered devices will be shipped to backers and those who have pre-ordered, though there may be delays for customers from the CIS countries due to logistics disruptions in the region.

*We refer to these events using the „officially approved“ wording in order to comply with the new law, violation of which is punishable by up to 15 years in prison.

Hier bleibt es zu beobachten, wie sich die Lage in den nächsten Jahren entwickelt und ob dies die Weiterentwicklung des Gerätes beeinträchtigt.

Fazit

Nachdem das Projekt bei Kickstarter ein großer Erfolg wurde, änderte das Team seine Pläne hinweg von einer Kleinserie für wenige Professionelle hin zu einem professionellen Anbieter von Pentesting-Geräten. Neben dem eigenen Shop soll in Zukunft auch über Plattformen wie Amazon geliefert werden.

Auf der Hardware-Seite erhält der Nutzer ein ausgereiftes Gerät und auch die Firmware weiß an einigen Stellen bereits zu glänzen, auch wenn es hier noch weiterführende Pläne gibt.

Aktuell findet der Support für das dynamische Laden von ELF-Binäries für die Plugins in der Erprobung. Im Moment müssen diese direkt mit der Firmware kompiliert und anschließend die Firmware geflasht werden. Das eröffnet die Möglichkeit, unterschiedlichste Plugins einfach mit dem Gerät nutzen zu können.

Bis zur Version 1 der Firmware, soll unter anderem die Dokumentation wesentlich verbessert und die Anzahl der unterstützten Funkprotokolle erhöht werden.

Die Kompanion-Applikationen wirken ausgereift und werden sicherlich in Zukunft durch entsprechende Updates aufgewertet.

Während das Gerät für Backer 119 US-Dollar kostete, beträgt der reguläre Retail-Preis 169 US-Dollar. Bestellt werden kann es über den offiziellen Shop, wobei mit längeren Lieferzeiten zu rechnen ist. Wer als Kickstarter-Backer seinen Flipper Zero noch nicht in den Händen hält, kann den aktuellen Status der Auslieferung auf ship.flipp.dev verfolgen.

Alles in allem erhält der Nutzer ein Gerät, welches viele Funktionalitäten, welche es früher nur einzeln gab, in einem kompakten System zusammenfasst. Mit weiteren Verbesserungen und Erweiterungen der Firmware und Kompanion-Applikationen wird der Flipper Zero zu einem wertvollen Begleiter.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Schaltplaneditor im Browser

Auf der Suche nach einem einfachen Schaltplaneditor habe ich vor ein paar Tagen Circuit Diagram entdeckt. Mithilfe des Editors ist es schnell möglich Schaltpläne zu zeichnen; auch Komponenten wie Arduinos und Co werden mitgeliefert. Der Editor läuft vollständig im Browser.

Der Schaltplaneditor mit einem Schaltplan

Die fertige Schaltung kann in unterschiedliche Formate exportiert werden. Zu finden ist der Editor unter circuit-diagram.org. Der Editor ist unter der GPL in der Version 2 lizenziert und damit freie Software. Der Quellcode kann über GitHub bezogen werden.

Erste Schritte mit Rust

Vor ein paar Tagen wollte ich die Programmiersprache Rust ausprobieren. Bei Rust handelt es sich um eine Sprache, welche syntaktisch stark an C angelehnt ist und besonderes Augenmerk auf Sicherheit legt. Die erste Frage, die sich mir stellte, ist, ob es für Rust, eine vernünftige IDE-Unterstützung existiert. Fündig geworden bin ich bei IntelliJ IDEA, welches nach Installation des Rust-Plugins zur Programmierung in der Sprache genutzt werden kann. Debugging von Rust-Programmen wird aus technischen Gründen nur in der JetBrains IDE CLion unterstützt, sodass hier einige Abstriche gemacht werden müssen. Neben der Rust-Integration für IntelliJ IDEA gibt es ebenfalls ein Plugin für Visual Studio Code, welches hier allerdings nicht weiter behandelt werden soll.

Mit dem passenden Plugin beherrscht IntelliJ IDEA Rust.

Neben der eigentlichen IDE wird Rust benötigt. Dieses kann über die offizielle Seite der Sprache bezogen werden. Nach der Installation kann in der IDE ein erstes Projekt angelegt werden. Anschließend findet sich in einem Ordner mit dem Namen src eine Datei mit dem Namen main.rs:

fn main() {
    println!("Hello, world!");
}

In dieser Datei findet sich ein minimales Hello world-Programm. Das Ausrufezeichen hinter dem println zeigt unter Rust an, das es sich um ein Makro handelt. Damit können Methoden und Makros einfach auseinander gehalten werden. Da ich Hello world-Programme immer etwas sinnfrei finde was das Lernen einer neuen Programmiersprache angeht, wollte ich für den ersten Versuch das Spiel Zahlenraten programmieren. Ziel des Spieles ist es eine Zahl zwischen 0 und 1000 zu erraten, welche der Rechner sich ausgedacht hat. Dazu muss im ersten Schritt eine Variable definiert werden, in welcher die zufällige Zahl gespeichert wird. Grundsätzlich sieht eine Variablendefinition und Deklaration unter Rust wie folgt aus:

let name: Typ = Wert;

Variablen in Rust sind immer Konstanten, wenn sie nicht explizit als veränderlich angegeben werden. Möglich ist dies mit dem Schlüsselwort mut:

let mut name: Typ = Wert;

Die Benennung von Variablen und anderen Elementen folgt in Rust einem bestimmten Schema. So werden Variablen snake_case benannt. Neben der Definition der Variable muss eine zufällige Zahl zwischen 0 und 1000 generiert werden. Dazu dient ein Zufallsgenerator, welcher über ein use eingebunden werden muss:

use rand::Rng;

Anschließend kann die Variable definiert und deklariert werden:

let number: u32 = rand::thread_rng().gen_range(0, 1000);

In diesem Fall wird ein vorzeichenloser Integer mit 32 Bit Breite als Datentyp definiert. Wird nun versucht das Rust-Programm zu kompilieren, so wird die Fehlermeldung:

error[E0432]: unresolved import `rand`
 --> src\main.rs:1:5
  |
1 | use rand::Rng;
  |     ^^^^ use of undeclared type or module `rand`

error[E0433]: failed to resolve: use of undeclared type or module `rand`
 --> src\main.rs:4:23
  |
4 |     let number: u32 = rand::thread_rng().gen_range(0, 1000);
  |                       ^^^^ use of undeclared type or module `rand`

error: aborting due to 2 previous errors

auftauchen. Grund hierfür ist, dass das genutzte Paket über den Paketmanager von Rust bezogen werden muss. Pakete werden über den Paketmanager Cargo bezogen. Die entsprechenden Pakete des offiziellen Repositorys sind unter crates.io zu finden. In der Datei Cargo.toml müssen die entsprechenden Abhängigkeiten eingebunden werden:

[dependencies]
rand = "0.7.3"
text_io = "0.1.8"

Neben dem Pseudozufallszahlengenerator, wurde gleich noch das Paket text_io eingebunden, welches später für die Eingabe von Text benötigt wird. Dieses Paket stellt hierbei das Makro read zur Verfügung, mit dessen Hilfe eine Eingabe realisiert werden kann:

let user_number: u32 = read!();

Damit sind die Grundlagen für das Spiel Zahlenraten gelegt und der Rest des Quellcodes ergibt praktisch sich von selbst:

use rand::Rng;
use text_io::read;

fn main() {

    let number: u32 = rand::thread_rng().gen_range(0, 1000);

    let mut running = true;

    println!("Ich habe mir eine Zahl zwischen 0 und 1000 ausgedacht.");

    while running {

        println!("Dein Vorschlag: ");
        let user_number: u32 = read!();

        if number > user_number {
            println!("Meine Zahl ist größer.");
        } else if number < user_number {
            println!("Meine Zahl ist kleiner.");
        } else {
            running = false;
        }
    }

    println!("Du hast die Zahl erraten. Es war die {}.", number);
}

Hervorzuheben ist, das unter Rust in if-Statements und Schleifen keine Klammern benötigt werden. Werden diese trotzdem genutzt, so warnt der Compiler entsprechend und bittet die überflüssigen Klammern zu entfernen.

Neben der entsprechenden Dokumentation auf der offiziellen Seite empfiehlt sich das Rust Cookbook als Quelle für die ersten Schritte unter Rust. Wer Rust einfach mal im Browser ausprobieren möchte, kann hierfür den Rust Playground nutzen.