Geschlechtergerechtes Coding – Gendern im Sourcecode⌗

In den letzten Jahren wurde das Thema Gendern in der deutschen Sprache zusehends hitziger diskutiert. Beflügelt durch die allgegenwärtige aggressive Internet-Diskussionskultur stoßen Bevölkerungsgruppen nicht mehr nur auf Internet-Plattformen wie Twitter/X unkonstruktiv und spaltend aufeinander, sondern mittlerweile auch in den klassischen Medien und im Alltag.

Gegenderte Sprache hat Einzug in unseren Alltag gehalten, begleitet von zum Teil absichtlich inszenierten Missverständnissen und aktiver Gegenwehr konservativer Sprachbewahrer, die unsere Sprache in Gefahr sehen.

Zugleich blicken wir zurück auf eine jahrhundertlange Ungleichbehandlung von Bevölkerungsgruppen auf Grund beliebiger Kriterien, die zu oft einem Machterhalt einer beherrschenden Gruppe diente und bis heute dient.

Ein nicht unerheblicher Teil unserer Bevölkerung hält daher das Einfordern einer Reflektion der eigenen charakterlichen Haltung gegenüber Geschlechterrollen über das Mittel gegenderter Sprache für ein verhältnismäßiges und geeignetes Mittel, und fordert diese Sprachveränderung aktiv ein.

Wir vom ICCB.dev als aufklärende Bildungsorganisation im Bereich IT sehen uns zur Neutralität verpflichtet. Deswegen werden wir weder für noch gegen das Gendern Partei ergreifen.

Wir wissen lediglich, dass Programmiersprachen auch Sprachen sind. Folglich haben wir untersucht, inwiefern das Gendern von Programmiersprachen funktioniert. Keinesfalls werden wir eine Empfehlung für oder gegen das Gendern aussprechen.

Gendern – was ist das überhaupt?⌗

Gendern bezeichnet die Sichtbarmachung aller Geschlechter an allen Stellen, an denen bisher das generische Maskulin die weiblichen Ausprägungen überdeckt. Konkret soll neben dem Bäcker auch eine weibliche Bäckerin sichtbar werden, genauso wie es neben dem Lehrer auch trans-orientierte Lehrer*innen gibt.

Das Mittel der Wahl ist hier eine von aufgeklärten Gruppen geforderte Änderung der Schreibung und Leseart der Bezeichner: Aus „Zuschauern“ werden „Zuschauerinnen und Zuschauer“, also einer Dopplung. Manche versuchen, diese Dopplung zu verkürzen und zugleich auch nicht-binäre Identitäten einzuschließen, indem sie „Zuschauer/innen“, „Zuschauer*innen“, „Zuschauer:innen“, „Zuschauer_innen“ oder „ZuschauerInnen“ (mit Binnen-I) daraus machen[1]. Ein winzig kleines Päuschen in der Aussprache soll nun an die Lücke erinnern.

Geschlechtergerechtes Coding?⌗

Wir stellen uns die Frage: Funktioniert das Gendern auch im Coding? Dazu müssen wir uns die konkreten Ausprägungen des Genderns genauer ansehen.

Leicht umzusetzen: Das Binnen-I⌗

Erkennbar einfach ist die Umsetzung per Binnen-I, also der Großschreibung mitten im Wort. Unter Programmierern ist diese Herangehensweise schon lange als „CamelCase“ bekannt, wo es in Klassen- und Variablennamen die einzelnen Bestandteile eines Kompositums deutlicher machen soll. CamelCase wurde im Windschatten der Objektorientierung mit Java und C++ ab Ende der 90er populär. Bis dahin war es der Unterstrich, der die Namensbestandteile der Komposita deutlich machte. Einer Umsetzung des geschlechtergerechten Coding als

Zuschauer_in* zuschauer_in = new Zuschauer_in();

oder

ZuschauerIn* zuschauerIn = new ZuschauerIn();

steht also nichts entgegen. Lediglich der konsequente Zusatz _in bzw. In muss unter Entwicklern etabliert werden und kann durch Static Code Checker in der CI/CD-Pipeline erzwungen werden.

Die Herausforderung mit dem Gender-Doppelpunkt⌗

Der Doppelpunkt wird in objektorientierten Sprachen wie C++ oder C# für die Vererbungsbeziehung in der Klassendeklaration sowie für die Methodendeklaration mit zwei Doppelpunkten verwendet. Um den Doppelpunkt für gegenderte Klassennamen zu verwenden, implementieren wir eine leere Basisklasse mit dem Namen in. Vorsorglich deklarieren wir auch gleich eine Plural-Form davon:

class in {};
class innen : in {};

Um die hier als Zuschauer benannte Klasse sowohl als generisches Maskulin als auch gegenderte Variante verwenden können, nutzen wir ein typedef, um die beiden Varianten gleichzustellen.

Gleichberechtigung und Gleichstellung sind zwei elementare Prinzipien in einer aufgeklärten heutigen Welt:

class Zuschauer;
typedef Zuschauer Zuschauer_in; 
typedef Zuschauer ZuschauerIn;
class Zuschauer:in {
        //   …
}

Die Vorwärts-Deklaration der Klasse Zuschauer ermöglicht es uns, bereits in der folgenden Klassendeklaration geschlechtergerechte Programmiersprache zu verwenden.

Durch die leeren Implementierungen der Klassen in und innen fällt im Output-Assembly kein zusätzlicher Code an – die Programme bleiben also genau so performant wie ohne geschlechtergerechtes Coding.

Das Gender-Sternchen und der Schrägstrich⌗

Schwieriger wird es jedoch mit dem Gendern mit Gender-Stern oder dem Gender- Schrägzeichen, da diese Symbole in Programmiersprachen Operatoren sind und daher eine besondere Bedeutung haben. Das Ziel sollte sein, im Code eine Ausdrucksfähigkeit zu ermöglichen wie hier dargestellt:

Zuschauer_in zuschauer;
Zuschauer_in zuschauerInnen1 = zuschauer*innen;
Zuschauer_in zuschauerInnen2 = zuschauer/innen;
Zuschauer_in zuschauerIn1 = zuschauer*in;
Zuschauer_in zuschauerIn2 = zuschauer/in;

Hier hilft uns Operatoren-Überladung weiter. Programmiersprachen wie C++ oder C# erlauben es uns, die Bedeutung der Operatoren so zu ändern, wie wir das wollen. Implementieren wir die Operatoren-Überladung so, dass sich am Objekt nichts ändert, dann lassen sich auch Stern und Schrägzeichen verwirklichen:

const int innen = 1;
const int in = innen;

class Zuschauer:in {
public:
    Zuschauer_in& operator* (const int& b) { return *this; };
    Zuschauer_in& operator/ (const int& b) { return *this; };
}

Mit einer Festlegung der globalen Variablen „in“ und „innen“ auf den Wert 1 steht die Ausdrucksfähigkeit auch für primitive Datentypen zur Verfügung

gehaltsliste.add("Gehalt Busfahrer*innen", gehaltBusFahrer*in);
gehaltsliste.add("Gesamtzahl Fahrer/Innen", anzahlBusFahrer/innen);

Klappt das Gendern?⌗

Teilweise. An einigen Stellen ist es noch nicht möglich, in allen Varianten zu gendern. Die heutigen Programmiersprachen sind dafür schlichtweg noch nicht bereit.

Insbesondere fällt bei den Gender-Varianten mit Operatoren-Überladungen schnell auf, dass die eigentliche Objektinstanz nach wie vor im generischen Maskulin sein muss.

Zuschauer_in zuschauer;
Zuschauer_in zuschauerInnen = zuschauer*innen;

Gleichzeitig verhindert auch niemand, das Gendern absurd zu gestalten:

Zuschauer_in zuschauerInnen = zuschauer*innen*in*innen;

Gendern mit Binnen-I oder mit Unterstrich ist hingegen ohne Probleme möglich und kann daher auch konsequent genutzt werden.

Fazit⌗

Wir stoßen beim Gendern in Programmiersprachen auf ähnliche Effekte wie in natürlichen Sprachen. In beiden Fällen ist die konsequente Umsetzung zuerst etwas mühselig und führt manchmal zu sperrigen Konstrukten. Genauso ist das Gendern in beiden Sprachwelten in einzelnen Fällen nicht korrekt möglich. Hier bleibt es bei einer nur teilweisen Umsetzung.

Oft genug klappt das Gendern im Sourcecode jedoch ohne Probleme. Die Kernbotschaft der Bewegung kann also auch im Quelltext transportiert werden.

Ob die Idee des Genderns in den eigenen Sourcecode übernommen wird, bleibt dabei jedem Individuum überlassen.

[1] https://www.genderleicht.de/genderzeichen/